To make things clear — DevOps is a methodology. The idea of this methodology is to create a new mindset. A mindset when developers and 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.
WITHOUT DEVOPS
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 main problem with all the above was the lack of cooperation and communication. As a result, the software couldn’t be delivered at a desired fast pace.
With DevOps
Now, take developers and operations, merge them into a single team, and drive them with the idea of mutual support. You get DevOps.
DevOps methodology allows delivering software frequently with minor iterable changes.
The benefits:
Users receive new features and updates frequently. Your customers receive new features and bug fixes more often. 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 imagine your server infrastructure more like an abstract concept. It’s 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.
- 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 ss 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’s better to sow the seeds of DevOps 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 tools we use on a daily basis no matter what project we deal with:
- Docker for containerization
- Jenkins and Circle CI for continuous integration and 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
