Having a DevOps approach for application and product development is like H2O to your organization. Yes this includes High-quality bug-free apps and products, Heights of innovation, One-click deployments and many more.
It’s wrong to assume that only enterprise businesses can benefit from or need a DevOps strategy. Whether you are an organization the size of Facebook or a one-man tech startup, DevOps is now a way of life and ignoring it can make or break a company of any size. The way DevOps is adopted in startups is completely different than how it happens in larger organizations.
The DevOps buzz
So what is DevOps? Well, much like the name states, we are talking about a union of Developers and IT Operations (aka Systems Engineers). DevOps is many things. It is a collection of best practices, a set of tooling and a philosophy that emphasizes automation and collaboration.
The term “DevOps” emerged from the fast-paced “agile” software development movement. Agile practices encourage short iteration cycles, frequent new function releases and close collaboration between development and business stakeholders. It’s made quick revisions a common practice, which in turn has increased the need to produce software in a way that delivers ideas to market in a much faster model. Both established companies and startups are racing to test their innovative ideas and provide value for their customers.
Not adapting to DevOps in your technology projects, will increase the risk of delay on your technology debt. DevOps is easiest to implement early on in a technology project’s life cycle. The longer is the wait, the more effort it would require to re-work DevOps in your workflow.
If you are building a startup, this kind of speed and iteration is very important. When you are developing software for a particular customer, you must determine which features are valuable to them as quickly as possible. According to Lean Startup ideologies, utilizing DevOps is a major component of eliminating the waste that occurs around the provisioning of the new servers, software installations and configurations, and during deployment across environments. Without this strategy, the tasks can be time-consuming and prone to errors. Getting the process automated helps the features to move quickly into production, which allows them to be tested and validated quickly, this helps in faster reaction time to your customers and less wasted efforts.
Evolution of DevOps @ Startups – Stage I
In this first phase, the development team often adopts Agile as a way to quickly iterate on the development process. These short-term sprints build the initial functionality of the product. While initially, there isn’t really much to release to potential customers, the core developers are starting to build their development and release cadence. This helps to keep the product requirements small and the team on-track to deliver a small piece of functionality in short period of time.
Often the development team is sitting side-by-side cranking out code quickly. No specs, just a list of what needs to be done often stored in Pivotal Tracker or some similar tool. Sometimes mock-ups and screens designed to describe the functionality.
There is a little formal process at most startups. Things are evolving and moving so quickly that there just isn’t time. The goal, after all, is to get a product into market and start selling. While startups are high adopters of Agile as a development methodology, there is generally little rigor in its implementation. There isn’t a well-developed end-to-end product release process. Also, the movement from development to operation is also not well defined. It is quite often that the developers who are building the product are the operations guy and managing the product and service.
During the first phase the DevOps sees some light of the day. Developers as they develop the code comes across some basic challenges and begins to solve the issue. The first things developers do is to spin up a environment to test the software. Most of the times, they will find a cloud provider, start configuring the environment to test the application. They might do this a few times, but as they test more and on different platforms they will start looking for some tools to automate the process. This is the stage, where there are most likely no operations people, and the tasks are done by the developers. And developers, looking at spending more time on coding picks-up some automation tool to do this work.
The tools might include infrastructure providers like AWS, Rackspace, or SoftLayer to configuration automation tools such as Chef or Puppet. There might be other tools for project management tracking, frameworks and libraries. Once they launch the product, they might also look towards monitoring tools to help them get visibility into their product. As things progresses, the developer would need the test environment quickly and repeatedly. The underlying pattern would be to move fast, solve problems, and quickly get to the market.
Evolution of DevOps @ Startups – Stage II
While tools are hardly a complete DevOps methodology, they are the catalyst for the next step in a startup’s journey to adopt DevOps. Many of the tools chosen in this first period have APIs, can create automation, and are highly configurable. As a startup keeps moving forward and increasing their users, the flexibility of these tools and the various ways that the developers utilize them starts to drive some conversation around process. A few problems in production environment with bugs, or outages and tech-leads start using the word Process.
The growth of startup starts to create desire to add control, accountability, and define the product development process. Agile now starts to extend up and down the organization in a more rigorous way. DevOps is starting to take hold and become more fully formed.
Evolution of DevOps @ Startups – Stage III
The early stage DevOps life-cycle wraps up with it becoming a part of the Culture. Now, methodology becomes fundamental part of the business. Values such as agility, customer focus, rapid iteration becomes core principles of the company. Hiring are made based on whether the candidates match the philosophy and culture of the company. DevOps is viewed as more than just a process that the company follows, but a competitive advantage in fulfilling its mission to its stakeholders.
Reasons for adopting DevOps
So, what are the best practices of DevOps? Why should you use them? And how do you get started implementing them? Let’s look at some of them.
Reason 1 – Your team has the best developers, but an application deployment takes three times longer than it’s supposed to take.
If it takes a long time for the feedback to reach the developer, it’s very likely that your developer has moved on to coding the next feature. Therefore, the context of the previous feature is not as fresh as it would have been if the feedback was sent quicker. When the very success of your new company relies on getting new code into production, anything that slows down “ship day” is unacceptable.
Reason 2- You end up doing lot of tedious manual steps.
A lack of automated scripts that take care of your repeatable tasks calls for tedious manual steps that are way more faulty given the involvement of the human element. This deprives you of sleep.
Reason 3- You have ideas booming among the team, but the practicality of the idea demotivates you.
Your team and you are full of creative and innovative ideas. But what about factors like cost, time and resource allocation that bring you down every time you think of a new idea? Not having a DevOps approach in place is prepping you to see the light of your organization’s doomsday.
Reason 4- You feel your Developers and Operations spend more time finger-pointing than actually working.
There’s a whole lot of finger-pointing and blame-game playing going on within your teams. No one wants to take responsibility. You are not really sure who caused the issue in the first place. This makes you miss your business goal time and again and deliverable date slip.
Reason 5- You are terrified at the thought of hiring new developers.
Irrespective of the size of your organization, you constantly face the issue of a lack of documentation. You let go of one of your current employees or he quits your firm for another job. What if the same employee was responsible for major developments and has failed to document his work appropriately?
It’s going to be a disaster for the new employee hired to replace him.