It is, of course, about . If you do not go into details, then on September 30 and October 1 we will hold a conference on combining the development, testing and operation processes, and if you go into details, please under cat.
Within the framework of the DevOps approach, all parts of the technological development of the project are intertwined, occur in parallel and influence each other. Of particular importance here is the creation of automated development processes that can be changed, simulated and tested in real time. This helps to instantly respond to changes in the market.
At the conference, we want to show how this approach affects product development. How the reliability and adaptability of the system for the client is ensured. How DevOps is changing the structure and approach of the company to the organization of the workflow.
behind the scenes
It is important for us to know not only what different companies are doing as part of the DevOps approach, but also to understand why this is all. Therefore, we invited not just experts to the Program Committee, but specialists who see the DevOps discourse from different perspectives:
- senior engineers;
- developers;
- team leads;
- CTO.
On the one hand, this creates difficulties and conflicts when discussing applications for reports. If an engineer is interested in analyzing a major accident, then it is more important for a developer to understand how to create software that works in clouds and infrastructures. But by negotiating, we create a program that will be valuable and interesting to everyone: from engineers to CTOs.
The goal of our conference is not just to choose the most interesting reports, but to present the big picture: how the DevOps approach works in practice, what kind of rake you can run into when moving to new processes. At the same time, we build the content part, going down from the business task to specific technologies.
Conference sections will remain the same as in .
- infrastructure platform.
- Infrastructure as code.
- Continuous supply.
- Feedback.
- Architecture in DevOps, DevOps for CTO.
- SRE practices.
- Learning and knowledge management.
- Security, DevSecOps.
- DevOps transformation.
Call for Papers: what papers we are looking for
We conditionally divided the potential audience of the conference into five groups: engineers, developers, security specialists, team leaders and CTOs. Each group has its own motivation to come to the conference. And, if you look at DevOps from these positions, you can understand how to focus your topic and where to place accents.
For engineers who are engaged in the creation of an infrastructure platform, it is important to understand the existing trends, to understand what technologies are now the most advanced. It will be interesting for them to get acquainted with the real experience of using these technologies and exchange views. The engineer will be happy to listen to a report with an analysis of some hardcore accident, we, in turn, will try to pick up and polish such a report.
For developers It is important to understand the concept of cloud native application. That is, how software should be developed so that it works in the clouds and various infrastructures. The developer needs to constantly receive feedback from the software. Here we want to hear case studies on how companies build this process, how to monitor software performance, and how the entire delivery process works.
Cybersecurity professionals it is important to understand how to set up the security process so that it does not stall the development and change processes within the company. The topics about the requirements that DevOps imposes on such specialists will also be interesting.
Team leads want to knowhow the continuous delivery process works in other companies. Which way the companies went to this, how the development processes, quality assurance within DevOps were built. Team leaders are also interested in cloud native. And also - questions about the interaction within the team and between the teams of developers and engineers.
For CTO the most important thing is to figure out how to connect all these processes and adjust them to business needs. He makes sure that the application is reliable for both the business and the client. And here you need to understand which technologies will work for which business tasks, how to build the entire process, etc. The CTO is also responsible for budgeting. For example, he must understand how much money needs to be spent on retraining specialists so that they can work in DevOps.
If you have something to say on these occasions, do not be silent, . The deadline for Call for Papers is August 20. The earlier you apply, the more time you will have to finalize the report and prepare for the speech. So don't delay.
Well, if you don’t have a need to speak in public, just and come September 30 and October 1 to communicate with colleagues. We promise it will be interesting and inspiring.
How we see DevOps
To understand exactly what we are investing in the concept of DevOps, I recommend reading (or re-reading) my report "". Walking the waves of the market, I watched how the idea of DevOps is being transformed in companies of various sizes: from a small startup to multinational companies. The report is built on a series of questions, answering them, you can understand whether your company is moving towards DevOps or there are problems somewhere.
DevOps is a complex system, it should have:
- digital product.
- Business modules that develop this digital product.
- Product teams that write the code.
- Continuous Delivery practices.
- Platforms as a service.
- Infrastructure as a service.
- Infrastructure as code.
- Separate reliability practices hardwired inside DevOps.
- Feedback practice that describes it all.
At the end of the report, there is a diagram that gives an idea of the DevOps system in the company. It will allow you to see which processes in your company have already been debugged, and which ones are yet to be built.
The video of the report can be viewed .
Now for the bonus: several videos from RIT ++ 2019 that deal with the most common issues of DevOps transformation.
Company infrastructure as a product
Artyom Naumenko leads the DevOps team at Skyeng and takes care of the development of his company's infrastructure. He told how infrastructure affects business processes in SkyEng: how to calculate ROI for it, what metrics should be chosen for calculation, and how to work on improving them.
On the way to microservices
Nixys company is engaged in support of loaded web-projects and distributed systems. Its technical director Boris Ershov told how to transfer software products, the development of which began 5 years ago (or even more), to modern rails.
As a rule, such projects are a special world where there are such dark and ancient corners of the infrastructure that the current engineers do not know about them. And the once chosen approaches to architecture and development are outdated and cannot provide the business with the same pace of development and release of new versions. As a result, each product release turns into an incredible adventure, where something constantly falls off, and in the most unexpected place.
Managers of such projects inevitably face the need to transform all technological processes. In his report, Boris said:
- how to choose the right architecture for the project and put the infrastructure in order;
- what tools to use and what pitfalls are encountered on the way to transformation;
- what to do next.
Release automation or how to deliver quickly and painlessly
Alexander Korotkov is the lead developer of the CI/CD system at CIAN. He talked about automation tools that allowed to improve the quality and reduce the time of code delivery to production by 5 times. But such results could not have been achieved by automation alone, so Alexander paid attention to changes in development processes.
How do crashes help you learn?
Alexey Kirpichnikov has been implementing DevOps and infrastructure at SKB Kontur for 5 years. Over the course of three years, about 1000 fuck-ups of varying degrees of epicness took place in his company. Among them, for example, 36% were caused by rolling out a low-quality release to production, and 14% were due to hardware maintenance work in the data center.
The archive of reports (post-mortems), which the company's engineers have been keeping for several years in a row, makes it possible to receive such accurate information about accidents. Postmortem is written by the engineer on duty, who was the first to respond to the signal about the accident and began to fix everything. Why torture engineers who fight at night with fakups, writing reports? This data allows you to see the whole picture and move infrastructure development in the right direction.
In his speech, Alexey shared how to write a really useful postmortem and how to implement the practice of such reports in a large company. If you like stories about how someone screwed up, watch the video of the performance.
We understand that your vision for DevOps may not be the same as ours. It will be interesting to see how you see the DevOps transformation. Share your experience and vision on this topic in the comments.
What reports have we already accepted into the program?
This week, the Program Committee adopted 4 reports: on security, infrastructure and SRE practices.
Perhaps the most painful topic of the DevOps transformation is how to ensure that the guys from the information security department do not destroy the already built links between development, operation and administration. Some companies do without an information security department. How to ensure information security in this case? About it Mona Arkhipova from sudo.su. From her report we learn:
- what needs to be protected and from whom;
- what are the routine security processes;
- how IT and IS processes intersect;
- what is CIS CSC and how to implement it;
- how and by what indicators to conduct regular IS checks.
The next report concerns the development of infrastructure as code. Reduce the amount of manual routine and not turn the whole project into chaos, is it possible? To this question Maxim Kostrikin from Ixtens. His company uses terraform to work with AWS infrastructure. The tool is convenient, but the question is how to avoid the appearance of a huge block of code when using it. The maintenance of such a legacy every year will cost more and more.
Maxim will show how code placement patterns work, aimed at simplifying automation and development.
Another we will hear about the infrastructure from Vladimir Ryabov from Playkey. Here we will talk about the infrastructure platform, and we will learn:
- how to understand if the storage space is being used effectively;
- how several hundred users can get 10 TB of content if only 20 TB of storage is used;
- how to compress data by 5 times and provide it to users in real-time;
- how to synchronize data between several data centers on the fly;
- how to eliminate any influence of users on each other when using the same virtual machine sequentially.
The secret of this magic is in technology ZFS for FreeBSD and her fresh fork ZFS on Linux. Vladimir will share cases from Playkey.
Matvey Kukuy from Amixr.IO prepared for real life examples , what SRE and how it helps build reliable systems. Amixr.IO passes customer incidents through its backend, dozens of on-duty teams around the world have already sorted out 150 cases. At the conference, Matvey will share statistics and insights that his company has accumulated by solving customer problems and analyzing fakups.
Once again, I urge you not to be greedy and share your DevOps samurai experience. Serve for the report, and you and I will have 2,5 months to prepare an excellent presentation. If you want to be a listener to the mailing list with program updates and seriously think about booking tickets ahead of time, because they will rise in price closer to the conference dates.
Source: habr.com