DevOps for Startups – Implementation & Best Practices

It’s hard to believe the DevOps approach has been around for about 15 years already. What started as a “simple” answer to the Agile way of work, by treating operations in the same way as development, has evolved into a methodology of driving organizations to more efficient, faster, and more robust delivery processes. 

Why is the DevOps approach so successful? 

Is it something suitable only for enterprises? 

Or are there reasons why smaller companies and startups should incorporate DevOps processes into their operations? 

This blog post will answer these questions.

1. What is DevOps?
2. Is DevOps suitable for startup companies?
3. The role of DevOps in a startup
4. How can DevOps benefit a startup?
5. How to implement DevOps as a startup?
6. Tips and best practices
7. How Spacelift can help with DevOps for a startup?

Before I answer these important questions, I should explain what DevOps is. It started as a bridge between development and operations, to help two areas that are very different in their goals and ways of working work together.

Over the years, DevOps has changed and grown into a fully functional model that drives organizations. DevOps is now present in almost all modern work frameworks and methodologies (so many *Ops out there!). But most importantly, we have learned how to structure DevOps as a useful and measurable tool.

How is DevOps different from traditional software development?

Just as Agile moved software delivery away from waterfall, DevOps changed the operations landscape. 

Before DevOps, operations teams were separated from development. Furthermore, these two areas had different goals. These differences emerged clearly after development adopted Agile. Whereas the goal for operations was stability, development tried to increase the speed of delivery and the number of deliveries in time. A clash was inevitable.

Apart from other changes, the initial goal of DevOps was to remove that conflict and position operations within the development circle.

DevOps frameworks

Today we use two main frameworks in the DevOps landscape: Three Ways and CALMS. Neither is new, but unfortunately, both are used only in more developed organizations. The truth is that using either of these will help to boost DevOps adoption and understanding.

Three Ways

Three Ways as a concept is explained in detail in the IT Revolution’s books The DevOps Handbook and The Phoenix Project. These books should be read by anyone who wants to be a good DevOps practitioner.

Three Ways embraces three principles.

• The first way: Systems thinking —  This principle focuses on the performance of the entire system, not specific silos. The goal is to increase the effectiveness of the flow by understanding and improving the value streams.
  

• The second way: Amplify feedback loops — If you are familiar with “shift left” principles, this principle will seem similar. It underlines the importance of feedback loops from right to left. In other words, how earlier stages should be informed about the situation by later stages.

• The third way: Culture of continuous experimentation and learning —  This argument (experimentation) is shared by the Agile and DevOps approaches. The fear of failure is a significant factor that prevents companies from being innovative and successful in the modern market.

CALMS

The second and equally popular framework is CALMS. This framework contains five pillars:

• Culture
• Automation
• Lean
• Measurements
• Sharing

We will not expand on each category. In essence, it maintains that DevOps is not just about the tools and automation, or cloud and CI/CD, but about the way the organization is run — how we use Agile methodologies (like Lean) to increase productivity, how we share knowledge, how we measure our progress, and how we automate processes. As well as that, we deal with culture and how the company works.

DevOps is clearly not just about tools or automation. In fact, automation, as part of the CALMS model (under the automation principle), is only a small part of the whole methodology.

It is important to note that you cannot “just” implement the whole DevOps way in your organization. It is a long process and should be approached step by step. This means that companies of any size can select the parts that fit their needs.

The short answer is: of course! DevOps is not limited by the number of employees, net growth, or anything else. The difference is in what is implemented and in what way. But first, the organization must answer fundamental questions: Why do we need DevOps? What problem do we want to solve? What do we want to achieve?

The mistake

The most common mistake made by startups is to hire a so-called “DevOps Engineer” to fill the position of someone who will provide systems administration, take the code from developers and deliver to the production, and be on-call. This role isn’t a DevOps role, it is simply a person — a system administrator in most cases — who performs the conventional duties of the position.

The role of DevOps in a startup should be primarily focused on establishing an effective delivery chain and measuring it. The key responsibilities lie in configuring and managing cloud resources (as most startups will use clouds) and enabling and enforcing use of infrastructure as code (IaC) and CI/CD systems. Let’s not forget monitoring, where observability plays a very important role.

But these are technical aspects. Every startup and every team needs a foundation to make sure that these practices will be implemented. Therefore, the major effort should be focused on delivering knowledge to the organization. 

In order to run fast, it is not enough to implement AWS, Kubernetes, and Jenkins. This will not help; it will just move problems elsewhere. We need to implement culture.

In this area, DevOps must foster collaboration between people, involve them in sharing (for example, by doing internal sessions describing “how we work” and “how DevOps can help”), and show the importance and profit available when proper tools and processes are used.

In the following table, we outline what Devops processes and DevOps engineers can help and  what isn’t in their competence.

Let’s sum up the benefits of DevOps for startups:

1. Improved collaboration

By its nature, DevOps focuses on collaboration between people. It is not just about everyday work but about sharing knowledge, upskilling others, and creating a fertile environment for experimentation.

2. Improved delivery

Using proper tools with defined processes increases the delivery rate and decreases the time-to-market.

3. Established standards

DevOps prioritizes proper standards and repeatability. Templates, modules, automation, and documentation are important for enhancing development standards.

4. Measurements

DevOps allows us to measure work in an actionable way. DORA metrics enable us to understand the process and implement improvements.

5. Automation

DevOps automation streamlines development and deployment processes, enabling startups to bring products to market faster and more efficiently. Automating repetitive tasks minimizes human error and enhances consistency and reliability in software releases.

If a startup wants to do DevOps, it needs to implement some practices. Some of them are listed above, especially the Third Way.

As mentioned earlier, the goal in introducing DevOps in startups is to implement proper processes. This means:

• Streamlining the work through established workflows. DevOps defines the workflows and helps development teams understand the processes.
• Providing all the necessary knowledge about processes to the team. 
• Establishing feedback loops and making them actionable. This element is crucial. It is important not just to establish feedback loops to have situational awareness but also to act on them.
• Establishing delivery processes, including tools, configurations, templates, documentation, and knowledge sharing.
• Being a significant part of knowledge-sharing efforts.

All these points demonstrate that the organization doesn’t necessarily need a role of DevOps engineer but rather a set of skills. Of course, in most cases, the team will not have all these skills, so a new person must be hired. 

I’d like to emphasize one point, though. If you introduce a DevOps person to the team, don’t stop at the technical part. Of course,  knowledge of the cloud, CI/CD tools, IaC, and operating systems is important, but you must examine the elements that allow DevOps to transform the organization.

There are a couple of things you should consider before implementing DevOps practices:

• Don’t focus on the tools — Although proper selection of the tools is important and people hired as DevOps Engineers must be familiar with them, the tools in the DevOps chain are “just” the transmission belt for the processes. Establish processes and ways of working and then select the tools that support the selected approach.
• Don’t be a “delivery guy” for developers — Yes, One of the goals of properly established DevOps practices is to create and maintain a proper chain of delivery, but DevOps is there to enable development, not to do the developer’s work. Synergy and a properly established process will bring developers close to the production and its delivery, giving them more control and ownership.
• Don’t increase the developer’s cognitive load — In DevOps, we must establish tools and processes in a way that developers manage the delivery (or deployments), but they are armed with a toolset that allows them to do it in as unobtrusive a way as possible. That is why we at Spacelift say that we enable developers to deliver infrastructure without leaving their tools’ landscape.
• Focus on culture — This part is forgotten too often. CALMS positions culture in the first place. Three Ways are about establishing the proper work culture. Establishing the proper approach here enables the organization to deliver faster and more comfortably for the technical teams.
• Share the knowledge —We all know the “shift left” principle, but very often it is wrongly implemented. Shifting left responsibilities and tasks without shifting proper processes, procedures, and approaches leads to a dramatic increase in cognitive load and burnout. 
• Small companies, startups, and other organizations often demonstrate chaotic management processes and push a lot to development teams or even individuals. It is tempting to try to hire a very experienced person and give them a lot to do. The problem is that humans have a limited capacity for managing things, so no matter how experienced we are, we will make shortcuts and mistakes if we are overloaded. Share responsibilities between people, and provide the proper processes, tools, and ways of working to make the work easier.
• Measure the work — The DevOps approach enables multiple ways to measure. We all use monitoring and observability to monitor the effectiveness of a product, but what about the processes? Implement DORA metrics to measure the effectiveness of processes you implement in the organization
• Enforce a blameless culture — We often say that Agile and DevOps are about experimentation. But how do you encourage experiments without blame? 
• Implement “Inspect & Adapt” thinking — Embrace the Continuous Improvement aspect of Agile and DevOps. Constantly improve your process and control its efficiency.

I mentioned earlier that one of the goals for implementing DevOps practices is to “shift left” ownership without increasing cognitive load. Spacelift facilitates exactly that by giving the organization the tools to streamline the processes, enable developers to have limited control over the infrastructure, speed up development and delivery, and enable the setting of best practices when working with IaC.

How do we do all of this? Here are some features that map all aspects mentioned earlier:

• Developers don’t need to be familiar with infrastructure and even with IaC. DevOps engineers (or platform engineers, etc.) can set behavior boundaries and environments for Developers, using Spaces, Blueprints, and OPA policies.
• Infrastructure delivery can be streamlined according to selected standards using OPA policies implemented in Runs.
• Developers can use their preferred method to work with Spacelift — using a GUI, or without leaving their tooling, with CLI, GraphQL API or Kubernetes Operator.
• Stack dependencies allow engineers to build and execute complicated infrastructure setups with ease.
• The Resources view gives interested parties easy and flexible ways to understand what is deployed and the status of deployed resources.
• User management and control is enforced by OPA policies, User management, and enhanced VCS integration.

DevOps is suitable for companies of all sizes. The implementation and main focus might be different, but the goal is the same in all cases:  improve and enhance development and delivery processes.

When implementing DevOps practices, don’t focus on the toolset alone DevOps is a complex way of thinking, combining tools, processes, and measurements.

Spacelift can help you organize the orchestration of infrastructure by providing a proper tool for streamlining the flow of delivery with supporting functionalities to optimize development elasticity for everyone.

Do you plan to implement DevOps in your organization? Or maybe you are seeking ways to improve your processes? Book a demo with our engineering team to discuss your options in more detail.