In a company’s early stage, the focus is on producing features for the customer. When the focus is tangible value, it’s natural for a software-as-a-service (SaaS) startup to fill its ranks solely with application developers. But when should a company invest in development operations, and at what level? If it has enough capital to hire four developers, should one of those four be DevOps?
Over the last few years we’ve continued to wrestle with this question. The value from an app engineer was so tangible, but DevOps was something else. Though no visible product was created, DevOps produced many accelerants. Incorporating development operations promised to make the other engineers faster, more effective and happier, but we always feared a sacrifice in features. The decision was similar to setting up robust automation testing—the value accrues, but the upfront cost is a hard pill to swallow.
We did it too late, and learned some interesting things along the way.
The Benefits/Advantages of DevOps
The benefits to incorporating development operations early on are many. As an immediate ROI, DevOps will add a lot of agility to your team by allowing your other engineers (and your quality control team) to focus on what they do best: create your product.
What is interesting is that the role always exists implicitly within your development team, but is more effective when explicit. If added early, this position can accelerate your team. If not added in time, each developer will play the role in part. The biggest difference between the traditional engineering role and DevOps is the context required: It is possible for a DevOps person to not really know the business rules of your system and still add tremendous value. This means anyone skilled in the craft can be put to work, which allows for quicker onboarding.
To better illustrate this, let me start by explaining deeper the importance of DevOps in a startup (and in companies of all sizes, actually). By implementing DevOps practices you will enable quicker product iterations. This is vital for a startup, as much of the success of a new venture depends on meeting release dates and getting new versions of the product in the hands of your users as quick as possible. Also, configuration management (CM) tools provide an inventory of all your software and configurations as a living documentation. Your infrastructure setup will be more predictable, you’ll have a better understanding of your stack. Centralized logging solutions and performance monitoring tools will enhance your monitoring and alerting. In short, investing in DevOps in the beginning yields valued dividends over time as you scale.
How DevOps Has Impacted Our Business
Establishing DevOps deeply improved our release process. We used to release new versions of our product much less frequently, taking 30 to 40 hours per month of a developer’s time. Now we are able to release much more often—at least three times a week. In the past we would barely release three times in the same month! Now it takes just a few seconds of a developer’s time, only requiring the push of a button in our continuous integration/continuous deployment tool (CI/CD) Atlassian Bamboo. Builds are run and the application is deployed continuously to our test environments over the course of a few days. After successful rounds of testing performed by our quality control team, we are then ready to push our new release to the production environment by hitting the little icon named “Deploy.” It is enabling.
This successful implementation of a CI/CD strategy also added much more transparency to our pipeline. Now everyone can see in a central place all the metadata about a release, including what product version is deployed to which environment, what is being deployed and by whom.
Another result we achieved directly with DevOps was agility in setting up our cloud infrastructure. In the old days we would have to log in to our cloud provider control panel and manually spin up new instances, waiting long minutes for them to start only so we could then secure shell (SSH) into them and make all the necessary installations and apply the required settings. Now, we can simply a run a script in Ansible (our CM tool) that sets up an entire environment for us. And since it is much cheaper now to provision and configure new infrastructure, we are now able to create an entire new process for testing new epics completely segregated from our main infrastructure. This has greatly improved our development processes, allowing for more flexibility, speed and control when developing and testing new product epics.
DevOps Excellence
During the past year, we have come across different DevOps professionals and learned a lot about the good, the bad and the ugly DevOps engineer. More importantly, we’ve learned what makes a great one. Topping the list of attributes is extreme attention to detail. Managing an entire infrastructure isn’t easy; it has a lot of moving parts. Being able to not get lost in the details is essential.
A great DevOps engineer also possesses strong process orientation and a passion for automation. To be supportive to the engineering team, he or she needs to understand deeply the current engineering processes and think of ways to streamline and automate them. The questions the DevOps engineer should ask include:
- What is our build process?
- When do we deploy to QA?
- How do we notify the Quality Control team that a new version is ready to be tested?
You need someone who can challenge the enterprise status quo and help to define best practices for developing and deploying systems.
Finally, as happens with the definition of the word, there is no definitive answer on where a DevOps team or individual fit in the engineering organization of a startup. At our company, the DevOps engineers report to the Enterprise Architect, who reports to the CTO. In other organizations we have seen DevOps engineers report to the Head of Infrastructure (who reports to the CTO), or report to the Head of Infrastructure (who in turn reports to the VP of Engineering).
It really doesn’t matter where it fits in your company architecture. First, define your company and vision, then define your org chart. Just remember to include a box for your DevOps engineer from the beginning!
About the Author
Rafael Neves, head of Enterprise Architecture at ALICE, has more than 8 years of experience with technology, having worked in the financial industry both in the sell-side and the buy-side for most of his career. Prior to joining ALICE, he served as head of Engineering at investment advisory startup Monetar. Before that, he was the head of IT Quality & Process of Brasil Plural, engaging in prominent projects such as the technological structuring of the bank’s Broker Dealer in New York. In 2010 he became the head of Algorithmic Trading in the first electronic trading desk in Brazil at Agora CTVM, the leading brokerage house in the Brazilian Exchange which he joined in 2008. Rafael earned a Bachelor’s Degree in Computer Science from Universidade do Estado do Rio de Janeiro.
