Updated 18 Jan 2022
Infrastructure management has always existed to some extent. Back in the 1980-90s, it was about finding space for all those servers and addressing basic availability demands. As with other aspects of IT, it has evolved exponentially since then. Mysterious system administrators who would silently appear out of nowhere to make your PC and Outlook work in the local network are still there, however, they are now joined by an already established and well-known group of “devops” – not exactly developers, but not system administrators either.
This new profession evolved alongside IT. When people do something again and again, they tend to automate it. In programming, this resulted in the introduction of such concepts as patterns, then Bootstrap, and other language-specific frameworks. In infrastructure management, various concepts have been developed, including cloud computing, active-active data center setups, and on-demand cloud services. This is when devops as an area of expertise became a reality.
So why are devops needed (and are they really?) since it can almost always be semi-covered by a regular engineer’s efforts? Whether it is worth your time and effort very much depends on your business model and your goals, but there are a few classic use cases – and if you find yourself in a situation similar, it might be worth thinking it over.
This use case applies when you or your CTO need to explicitly empower the development team and ensure everyone is focused on the product delivery and addressing business needs as fast as possible.
You need to deliver the product but releases are taking time, and the faster you go, the more time they tend to take. Why can’t we just release small increments every few hours? Cloud services that are supposed to make it work out of the box somehow do not seem to apply to some crucial specifics of your architecture. You need it to be “slightly different”, so you end up with a mountain of release work, CI/CD work, environment management, and those sorts of things which are quite hard to justify to your sales team when explaining why a new premium feature gets delayed.
Moreover, your engineers are telling you it may not have been their job to renew that suddenly expired SSL certificate during the night. You push or apply some temporary measures but HR starts raising the topic of attrition and the learning curve for newcomers.
We could go on and on, but the bottom line is, you clearly need a devops function here so you could see and control how it’s done while focusing on what’s most important – building your product and beating the competition.
There is a common saying that goes – “if regulators start paying attention to your business, you can open the champagne, success has arrived”. It could be frustratingly different, however. A data privacy or KYC-related penalty notification has been delivered, and the amount mentioned there somehow exceeds your annual gross revenue.
Making your data and your infrastructure processing compliant is a relevant matter from day one. Leading cloud providers claim that if you use their infrastructure, your business will be compliant by default. Unfortunately, this is rarely the case. Your business is your business, and it is by definition unique and competitive, otherwise, you would not have started it.
So it needs to be controlled and thought through, and not only with regard to how you store or process your own data, but also which services or suppliers you employ and how they operate.
Such audit and mitigation actions usually start from architecture and topology analysis performed by infrastructure specialists, CISO, or security experts which we also consider to be part of the devops world. In most cases, the resulting mitigations are simple and cheap, just as most things are usually simple when done in a timely manner.
When an MVP version of your product was started, performance and scaling concerns were raised, but the product-market fit was really the most critical topic.
So the fit was found and the conversion numbers are going up pleasantly. You just need a couple more environments for demos though, as there are a few large enterprises who are considering buying but need just one more demo for another stakeholder. Also, they have been asking if they could install your platform on their premises and you’ve got just two environments in AWS now, which are working just fine so far. After a few months, your whole development team is busy making five environments that are stable for Sales demos while making the platform AWS-agnostic (their cloud functions and OCR service came in really handy in those early MVP days). Meanwhile, a client-specific feature has been delayed for another month and you are losing valuable tempo.
Here’s another example – your app has been featured on App Store’s “Our Favorites” list. The next day, your backend has been down several times and is still recovering. It’s hard to estimate how many premium conversions were missed. You have called infrastructure support, and they recommended you to “raise a ticket”.
Scaling, high availability, disaster recovery rehearsals, and flexible regional deployments may become relevant for your business much earlier than you expect. If you manage the cost vigilantly and plan for maturing and optimizing your platform design, you are likely to enjoy (and be ready for) exponential growth much sooner than your competition expected.
The pace of IT development has grown tremendously in the past 15-20 years. What had to be done completely from scratch each time back in 2004, is now entirely in the hands of an engineer on the first day of any product development. But this velocity comes with its own demands: there are other roles and areas that require attention so that everyone can do their job effectively, and the business grows in a secure, compliant, and easily scalable manner.
Our newsletter (you’ll love it):