When I started practicing DevOps in 2015, the term DevOps had been around for several years already. However, there weren't any definitive answers on how to handle cloud infrastructure and release developers' code to production.
Many companies didn't realize they needed to think this way since they had their developers and operations handle the lifecycle of their applications.
The developers would build the code, QA would test it, and operations would deploy the code to production using checklists, scheduling hours of downtime windows, and running scripts or replacing the new code manually on the servers.
Over time, organizations realized the benefits of adopting methodologies to reduce the time it takes for new code to reach production safely.
Fast track to 2022, We can identify a few major shifts in thought.
Here is a short explanation of how DevOps evolved, but in a funny way:
Simply hiring a DevOps expert will increase the release time by a small percentage but won’t solve the main pain points. Once the best practices are implemented, the investment will bear fruit in release time, deployment standardization, security, and microservices management.
Many organizations found that separating the huge monolith into smaller microservices reduced the release time and increased fault tolerance.
The easiest way to solve something was by writing a script to handle some kind of a repeatable task. Over time the scripts would grow and often break which resulted in maintaining scripts that only a few knew and understood how they operate.
Now there are many open-source and commercial solutions for most repeatable tasks. Occasionally teams would write wrappers to compliment and ready-made solutions to suit the organization's needs.
When having everything in one place inside the monolith, it's easy to handle the communication with each other and adjust the dependencies between them.
Although the Monolith has its advantages, many organizations found that separating the huge monolith into smaller microservices reduced the release time and increased fault tolerance. By doing that teams could ship faster, be more agile and iterate consistently.
Things get complex when having separated microservices on different servers with different runtimes, scaling, and security concerns.
It depends on the size of the company, but the general guideline is to have owners for each pillar. If there are many owners, they should coordinate on a regular cadence to accommodate the business goals. It’s easier when there is a budget for building separate teams with a clear goal, and harder for small companies as their main focus is to grow.
When the company understands that they need to start adopting the DevOps methodologies they either set to hire a DevOps Engineer or use an outsource company.
Large organizations that have already adopted the DevOps ways have different teams who can address those concerns:
In short, the CTO and the developers.
Most of the companies that are between the pre-seed and round A phase (or before product-market fit) don't take most, or all of the 10 questions asked into consideration.
The results of focusing only on building the application could be:
When the company understands that they need to start adopting the DevOps methodologies, they either set to hire a DevOps Engineer or use an outsource company to assist them.
There are great companies that can take the entire refactoring project off of the company's hands from designing and planning with experienced cloud architects to professional DevOps practitioners who will build and sometimes even operate the entire cloud infrastructure, release flows, etc.
Most of the time, they will assist with answering the ten questions.
While this can suit many companies, the costs are rather high for a Startup to handle at an early stage, and there is a significant overhead with managing a 3rd party contractor.
It's becoming harder and harder to hire an experienced DevOps Engineer, but even when found - the chance that they will solve all of the issues is not high since it's too much to handle for a single person who is pressured of making poor decisions.
As a result, the company can end up hiring additional Engineers and eventually someone to lead the entire culture.
Many Startup companies after the round A phase are looking for a "one-man show" to avoid the mistakes of a never-ending hiring spree.
Finding someone to instill the DevOps culture inside the company with the proper skills of a cloud architect, systems administrator, security, testing, and automation is near impossible to find. This could get costly with high demanding salaries and the time to find one.
Once found and held for dear life, they are tasked to fix and refactor all of the accumulated issues that were neglected or poorly implemented, and over time they churn as sometimes they are chasing their own tail in order to fix production and development environments.
They wish to be involved during the decision-making process and to build production-grade environments with best practices.
Invest the time to educate the development team on the proper microservices best practices on the cloud as they do with software development best practices.
In short, “strike while the iron is hot”. They need to address the issues even before they become issues while having the knowledge for setting up the proper foundations at every milestone.
We saw that only focusing on the application development can result in delays in deadlines, and companies understand they need to invest in DevOps methodologies at a later stage when the cost of refactoring is very high, both in terms of actual money and time.
Having someone to lead the DevOps space early on and eventually becoming a high-performing team will increase the company’s time to market by 10x, if not more.