By the end of this article, you will get a general idea behind DevOps approach. I will describe how DevOps is implemented in our company and why it’s so great to develop software sticking to DevOps practices.
What is DevOps?
To make things clear—DevOps is a methodology. The idea of DevOps methodology is to create a new mindset, when developers and IT operations combine their efforts to achieve a common goal.
Sometimes it is mistakenly confused with a tool or a role. It’s not a tool although it uses a toolchain to automate software delivery and deployment. Nor it’s a position although both operations and developers are expected to extend their responsibilities.
A lack of cooperation and communication leads to slow speed of software delivery
Traditionally, or say 10 years ago, the development team could be roughly divided into developers—people who knew how to write code, and operations. For those who still wonder who on earth are those operations:
They are administrators—sysadmins, network admins, database admins, and all other people who know the infrastructure.
So... The operations were interested in keeping things stable to minimize the chance of software conflicts. While developers mostly cared about new features, new versions, and well, yes bug fixes. The developers and operations were isolated of each other. Because of this isolation there was a lack of cooperation and communication. As a result, the software could not be delivered at a desired fast pace.
DevOps methodology allows to deliver software frequently introducing minor iterable improvements
Now, take developers and operations, merge them into a single team, and drive them with the idea of mutual support. You get DevOps.
The benefits:
- Users receive new features and updates frequently. As a side-effect, your company becomes more competitive.
- Minimize the chances of outrages. Even when the outrages do happen, everything can be fixed in a matter of minutes (sometimes in a matter of a single refresh) so that users won’t even notice that something is wrong.
What’s More
Except for the cultural component DevOps methodology became possible thanks to the following approaches:
- Infrastructure as code is an approach when servers can be configured automatically. The idea here is to treat your server infrastructure more like an abstract concept. It is easy enough as a lot of today’s servers are cloud-based. Next step is to simply describe the configuration of your servers in a configuration file. The benefits here are the following: you can configure any number of servers really fast, all the configurations are documented with the same code.
- Microservice architecture is an approach in software development when the application is divided into loosely coupled parts. Imagine you have a modern social media messaging app with chats, stories, voice calls, bots and so on. All these can be developed like independent mini applications. This approach makes it easier to maintain, test, and reuse parts of the application. On the other hand, the development process becomes more complicated because code consists of more parts. Developers should think of communication between services within applications.
- DevOps loves automation. Automation is demanded by modern insanely fast operating software development industry. Dozens of continuously integrated builds are queued for a deployment...daily. There is no way you can manually test them all. Same applies to server configuration. There is no way you can set up 20, 50 or even 100 servers, manually.
- DevOps utilize the arsenal of tools. Most of DevOps aspects won’t be possible without tools like Jenkins, Ansible, Docker or Puppet. Still, the tools only facilitate the process and allow to achieve the goal. Knowing how to create Docker container doesn’t necessary mean that you are in a DevOps club.
Why do You Need DevOps?
It all depends on the scale of the project. If your objective is to launch a minimum viable product(MVP) to test your idea, most likely you can live without DevOps practices. If your software has already reached several releases, and it is time to start thinking about scale and competitiveness—think of DevOps.
It takes more time to set up DevOps environment from scratch. On early stages people get confused why should it take additional time and money to setup Docker and Ansible. The answer is simple—it will take a bit more time now, and as a result, save it in a long term perspective.
How We Implement DevOps
In Django Stars, the implementation greatly depends on a customer we deal with. Here is the list of the most frequent “types” of requests:
- Customers who want to build an MVP
This is the most frequent request, simply because one day, any company has passed the initial stage of MVP. For such little projects adding a release engineer or system administrator would be an overkill and a waste of customers’ money. These projects are often deployed by developers themselves.
We try to convince the customer that it is better to sow the seeds of DevOps methodology on this early stage and stick to DevOps common practices like building an app using microservices. In most cases, the developers will also deploy and maintain the product. It allows minimizing the spendings. The product itself is built according to customer preferences, but even if the customer prefers the monolith type of app, opposed to microservices, still we create a good foundation to implement microservices in future.
- Customers who already have part of the project developed by someone else
Most of the time is the hardest case. We like to avoid projects that have been started by someone else and for some reason were abandoned. Still, there are some rare exceptions when the projects are promising enough to take a risk. The cases exclusively depend on the customer. Sometimes, we get an app developed with best DevOps practices in mind, with a request is to upgrade the app from Python 2 to Python 3. While another one required a complete rewrite from the ground up.
- Long term customers and partners with mature applications
This case is the most relevant to a “perfect DevOps world”. Our software engineers are working in a tight conjunction with customer's operations or DevOps engineers.
Whenever we get a request to implement a new feature our developers provide the following info to customers’ ops teams:
- Required dependencies
- The expected load feature can handle
- Services affected by the upcoming feature
The ops team sets up servers according to developers requirements. This, in turn, makes the further life of our developers easier.
Our Toolchain
Here are the DevOps tools we use on a daily basis:
- Docker for containerization
- Jenkins and Circle CI for continuous integration and continuous delivery
- Sentry for real-time error tracking
- ELK for metrics, and logging
- Terraform and Ansible for server provisioning and infrastructure
- Nagios and New Relic for monitoring
You can check our CI comparison and Docker tutorial on our blog
Conclusion
DevOps is a methodology that allows to develop and deliver software more efficiently than a traditional siloed approach. It is not solely limited to developers and IT operations. In most cases, the approach is also spread on QAs, PMs, and Security experts. Companies that implement DevOps on early stages create grounds for scalable growth.
The article is written by Volodymyr Dmytriiev.
This article about who is devops is originally posted on Django Stars blog. You can also visit our content platform Product Tribe created by professionals for those involved in a product development and growth processes.
You are always welcome to ask questions and share topics you want to read about!
Top comments (0)