There have been huge changes in the Information Technology and Operations (IT/Ops) sector recently. Most have to do with the element of control exerted by various parties over the infrastructure required to deploy a website or app. This article covers changes in how IT/Ops teams operate, what these teams are responsible for, and the implications of companies merging their IT/Ops and engineering teams.
A Very Brief History of IT/Ops
As recently as ten years ago, IT/Ops controlled everything. IT/Ops teams’ responsibilities included (but weren’t necessarily limited to):
- Provisioning infrastructure by leasing or purchasing hardware located in data centers
- Setting up and maintaining all hardware
- Working with engineering to adapt, configure, and deploy IT/Ops infrastructure
In sum, IT/Ops owned and controlled nearly 100% of the infrastructure required for running an app or website. They were essentially the gatekeepers to all things hardware.
The Upside of IT/Ops
The primary advantage of having all infrastructure fall under the responsibility of a dedicated IT/Ops team is that they are skilled in filling in gaps in engineering’s areas of expertise. For example, IT/Ops teams are extremely competent at:
- Maintaining and scaling systems as resource demand fluctuated
- Ensuring best practices, such as making backups at regular intervals
- Handling infrastructure configuration and security
The Downside of IT/Ops
Having a dedicated IT/Ops team isn’t all upside, however. The biggest disadvantage, due to the fact that IT/Ops owns all aspects of the infrastructure and acts as a gatekeeper, is a lack of nimbleness. Your ability to respond to changes quickly suffers, which is problematic on multiple levels. Delays may result from waiting for new infrastructure implementations, ensuring that all teams (not just a select group of people) are onboard with the desired changes, and, finally, waiting for all parties to carry out the necessary tasks to deploy. If you’re in a fast-changing market, these things result in your decreased competitiveness as compared to your peers.
For example, if you, in engineering, are building an app with intensive hardware requirements, you must first coordinate with IT/Ops to procure it. The procurement process, depending on the demands of your company, can take a fair amount of time. You must account for capital costs, coordinate the schedules for all involved parties, and ensure effective cross-team communication regarding projects needs and growth. All in all, there are a lot of things that need to be done before you implement the necessary infrastructure, and all these tasks don’t just cost time, but also money. In a fast-changing market, this can be the difference between maintaining or losing your competitive edge.
Modern IT/Ops practices, however, look quite different from the legacy model described above.
The biggest change comes from the rise of cloud infrastructure providers, such as Amazon Web Services or Microsoft Azure. Rather than jumping through numerous hurdles to get infrastructure set up, you can now spin up the infrastructure you need using an API or a command-line program. Cloud providers have rendered a lot of the tasks once completed by dedicated IT/Ops teams unnecessary.
What does this mean?
In short, developers do not need to involve a dedicated IT/Ops team to deploy their apps. As a result, developers are capable of being extremely quick and nimble, especially when it comes to providing new releases, bug fixes, and updates (they may even be able to deploy continuously).
Furthermore, developers can update their hardware stack early and often. Without investment in physical capital, developers can scale up, scale down, or move their app to different stacks as needed. If one cloud provider doesn’t offer what the developer needs, he or she can seek out another provider. Not only does this save money in terms of hardware costs, but it also means that developers have access to the best possible tools for their needs at any given time.
Are there any downsides to the merging of IT/Ops and engineering though?
There are always downsides when you outsource any aspect of your development pipeline.
First, when an organization no longer controls its infrastructure, they are now hosting the code they produce on someone else’s equipment. Depending on the cloud provider, the organization may have very little control over the equipment on which their code runs.
Second, apps and sites running on cloud infrastructure are more likely to include third party components, whereas these items were once installed and hosted on the same servers as the primary application. Furthermore, these components, such as A/B test frameworks, analytics suites, and chat widgets, are likely running on other cloud providers’ infrastructure. All in all, everything is widely distributed.
The upside is that any downtime is unlikely to affect all aspects of an app/site simultaneously. The downside (and a big one at that), is that tracking, monitoring, and ensuring that all components are functioning becomes more challenging.
How do I manage the complexity involved with using cloud infrastructure?
Monitoring the sprawl created by cloud infrastructure can be complex, but it is important to do so, since you need to know before your users that something (be it unexpected downtime or the need for maintenance) has gone wrong and needs attention. Rigor can help you implement a thorough and easy-to-use monitoring solution for every aspect of your cloud infrastructure, no matter how big or how much it sprawls, so that you know exactly what’s working and what isn’t at every moment.
For additional information on how Rigor can help you monitor your apps and websites,