Rethinking Conference
Attitudes towards conferences in the IT environment are ambiguous: some in a boiling atmosphere of meetings feel like a fish in water, others are more likely annoying because you will not hear anything worthwhile or new to work.
Nevertheless, conferences are useful, and participation in them allows you to share knowledge and find out what breathes and in which direction the industry is moving. And if the conference is held in another city or country, it is also a great reason to see the world. The main thing is that participation does not become an “academic tourism” sponsored by the employer.
We told about the history and culture of the process in past articles, and today, under the cut, my story about how one trip can change the outlook or, at least, leave a mark in DevOps pioneer soul.
As an application developer, at the time of the trip, I had experience in pilot implementation of DevOps practices in projects, and I understood which processes were built well and which I would like to improve.
')
Surely you ask why I decided to publish when several months have passed since the date of the trip: the story below is not about tourist adventures and excursions in Munich, but what happened in the bottom line. It takes time to settle and test.
Airport, Munich, Conference
Munich is the IT capital of Germany, this is due to the fact that a large number of IT companies are concentrated in the city. The city was met with silence, and the upcoming DevOpsCon 2017 conference, in the program of which more than 45 reports were announced, inspired the joyful expectations of live communication with the leaders of the movement.
The first day of my participation in the conference was Russel Miles with the theme “Better software development systems through stress”. Speech was a kind of greeting for the assembled engineers who were skeptical, who thought that "Devops are toys, but in real-life development is a bit more complicated."
Charismatic Russel with a non-standard approach was able to entice skeptics, playing the guitar and singing the song, skillfully presenting information and inserting partly humorous theses, such as Production hates you! “Failure is EVERYWHERE!” and the introduction of applications in chaos, without receiving unexpected problems and critical errors. Utopian, but I really liked it.
Russel Miles at one of his performances, Break with Networking
Maneuvering between the halls, I lingered on a speech by Roland Huss, a Red Hat software engineer working on fabric8, a microservice platform for Kubernetes and OpenShift. The theme of his speech was: "Become a Cloud-native: Java development." I hooked up a few interesting approaches that make the transition from traditional Java development to microservice using kubernetes less painful or even painless. Roland told about the main selected environment creation tools: docker, kubernetes, fabric8, how it all interacts with each other, as well as how to put together a mini-cluster to practice working with microservices and creating infrastructure. The speech turned out to be entertaining: first, he told about the basics, and then, before our eyes, he wrote a simple application, created a docker image, set up the environment, and deployed the written application.
I want to cite several theses from the speech of Andre Neubauer and Thomas Uebel, who spoke with the topic: “Implementing DevOps strategies in DevOps averse environment”. For me, these simple but important points for awareness and perception of the problems of implementation and DevOps:
• an attempt to isolate or hire a devops man who will solve the problems of one and all;
• desire to automate everything and everyone;
• desire only to automate;
• attempt to transfer the competence of the operation to the design and abandon
The thesis voiced by the speakers is very close to me, for them DevOps is first of all a different way of thinking from the usual way, a short feedback loop due to the small iterative increment, as well as “the next logical step in the long journey called“ Agile ”. All in essence.
At the conference there were many stands of such companies as Atlassian, Appdynamics, Cyberark and others. Most of them provide services and facilities for creating a platform, organizing infrastructure, monitoring the network and others, but there are representatives of companies that help with the transformation and transition to more efficient development. Most of all, I was interested in the guys from Appdynamics, who demonstrated their own development - a system for monitoring a complex of applications. We reproduced the negative case in their application, unaccounted for by the developers, and then we were able to track which nodes walked our request, how long it was processed and on which line of code in which class NullPointerException occurred. Very useful stuff! In my work, I came across problems of defect detection: the same scenario, a set of screen forms can be developed by several teams. It was then that such a system would be very useful to me for monitoring.
Colleagues from AppDynamics
Separately it is worthwhile to dwell on the Atlassian company, whose products are used by many large customers all over the world. In my practice, Confluence and Jira, which help synchronize the work of teams. This is a single information field where the entire knowledge base of work rules and technologies, participants and products is stored. We use this platform to discuss the changes made, gather ideas and publish news.
Confluence has a set of tools that are of great help in DevOps processes:
The speech of Christian Koch “Deployment pipelines in the enterprise” was especially useful for those who work with large enterprises. Christian highlighted the main problems faced by large companies when trying to speed up the delivery of new features to the industrial environment, and then showed how to achieve the goal. One of the main ways is to create a working environment in which there will be a fairly high level of automation - tests, assemblies, analysis. This will allow not to waste time on manual labor, but at the same time in time to “remove from the conveyor” an assembly with a bug or an idle configuration. Thus, each company has only to define its own set of tools that will help ensure quick delivery of the working assemblies and at the same time will not allow anything to break.
This is exactly how Christian sees the abstract toolkit, which will speed up the frequency of releases.
The key value of any conference is networking. I took the opportunity to clarify for myself a few points that I had been thinking about for a long time. For example, find out whether representatives of companies that have long been involved in automation and work on flexible methodologies can safely say that they are “in DevOps” or “in Agile”? As expected, none of my interlocutors dared say so. Everywhere there were some "but" or "if", and some said that they only think about how to measure how devops & agile they are. For the rest of the evening, we talked about optimization, automation, and other aspects of "applying common sense to engineering." This is the combination I heard more than once from my interlocutors, while we were trying to figure out what DevOps and Agile are. But I was especially surprised by the engineer who drew an analogy between devops and beer fermentation.
How do you think there is something in common in these completely unrelated processes?
By the way, the topic of agile & devops was relevant - it was continued by Ovidiu Pitic, the head of Agile practices in Europe at Cognizant in his “Fueling Digital Transformation with DevOps” presentation.
I admit that this presentation was liked more than others: it appeals when the company, when making any serious decision, from young to old, every employee was guided by honest, basic principles of Agile. It doesn’t look like “worship” or “elevation” of Agile, it’s rather similar to the fact that they “accepted” these rules and principles, and everyone determined for himself why he followed them.
When the first enthusiasm subsided a bit, there appeared a craving for unhurried reflection, savoring new ideas and the information received. In this regard, the format of the Philipp Garbe report on “is Platform Engineering is the new Ops?” Was very successful.
He began his speech with a quote:
Philipp told how they first moved away from the separated development and testing teams, then identified the DevOps engineers, what problems they faced and how they came to the organization of engineering teams that are fully responsible for both the development and the operation of applications. The main message of the speech, as I understood for myself, is the selection of two types of engineering teams: platform and product. The former provide a functional and reliable environment so that the latter can quickly and safely deliver new features to users and receive structured feedback. It seems to me that this approach makes sense, especially if an application implies a whole software complex, and the complexity of the system environment is quite high.
Speech by Michiel Rook, Java consultant, PHP, Scala from the Netherlands, with the report "Database Schema Migrations with Zero Downtime", was a bit boring for me. The speaker enthusiastically and in front of the amazed public confirmed the conjecture that with database migrations, everything is simple if you do not use databases. This presentation was not a colossal discovery, since we do not use the database update scheme indicated below.
Michiel described a number of rules, resorting to which you can reduce downtime during database migrations. For example, the use of a load balancer to be able to disable one of the nodes on which the application is installed to install updates.
He also mentioned that in order to facilitate work with databases and reduce errors, it would be good to:
1) “break the link” between database migration and software deployment;
2) maintain backward compatibility and only expand interaction contracts;
3) to abandon destructive changes;
4) use feature toggle when working with data. For example, to remove old, replaced with new table fields.
Well, there is always something to learn.
But the Atlassian Tony Grout talk on “DevOps teams and the future backward” was entertaining. In his speech, he focused on how the principle of “openness” helps teams to achieve goals, while avoiding mistakes and not losing details. He demonstrated how teams can make decisions, experiment, try and learn, and how such an approach enhances the return of teams. We also discussed the problems of large corporations working with teams: the inability to work remotely due to security restrictions, the slow development of teams due to the lack of a culture of cooperation between different departments. Tony, I think, is convinced that today there are no restrictions for the remote work of employees and for the organization of inter-team training, that is, the creation of a “culture of cooperation”, as there are a huge number of technical utilities for effective team interaction.
The main principles of the approach:
At the end of the speech, Tony uttered a phrase that inspired me: “Be the change you seek“.
Initially, I thought that DevOps was about automation, scripts. A fairly common misconception, as I later learned and understood, plunging into the process and on Wednesday all the deeper: DevOps implies not only a certain technical warehouse, but also a psychological one, it is closely associated with flexible development methodologies. Participation in this conference allowed me to sort out and build the knowledge in my head into a coherent picture.
Cases, insights and networking excite an inquiring mind, and perhaps even provoke an internal philosopher - DevOps is the mindset of every participant: from business and stakeholders to implementers. You can’t just take it and bring it to the company by hiring a certain type of engineers, managers or transformers. Devops goes hand in hand with Agile. This is what you need to cultivate, instill, experimenting long and hard. The way of thinking is worth changing not only in terms of software development, but also in terms of customer interaction, feedback, and removal of metrics.
Of course, you cannot go far without engineering culture: while some guys will tirelessly find defects and flaws, repair them, others will produce new functionality, not really worrying about whether their methods are optimally written and whether they will correctly handle negative cases during the testing, There are no small iteration cycles. Do not forget about automation, the high level of which will significantly reduce the time for the withdrawal of new functionality in production, and this is probably one of the weak points of many companies today.
In the wonderful book The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, the “three ways” approach is described. The first way calls to focus on the performance of the whole system, rather than its individual components. Following the second path means building a short feedback loop, which will allow you to hear and understand all the customers of the system and react correctly to their feedback. The third way is to create a culture of experimentation and hone skills. When we try something new, it will require taking certain risks and setbacks, but it will allow us to develop and become better, and the next time, in an unpleasant situation, we will know for sure how to get out of it.
It seems to me that these three principles best describe the DevOps culture to which we all strive, however, some principles of the banking system, their current organization and worldview of some people do not allow these principles to be followed to the necessary degree. I think the point is also that DevOps is a relatively young direction, because of this people have a skeptical attitude, and sometimes, when trying to apply this methodology, there are more questions than answers
I like the approach of the cognizant company, which really “flexibly” approached the matter, but at the same time did not lose as “quality”: DevOps for them is not the goal itself or even the tool for solving certain tasks, rather it is a certain way, passing on which they will be able to constantly develop and provide users with the best products.
Devops is a unique practice of learning and experimenting, where something new is always welcome. Without mistakes, nowhere, but in this case, mistakes are what drives forward, they should not scare, demoralize, they should be learned and draw conclusions. After the conference, I deployed my approach 90 degrees, because I was convinced that in such matters as the transformation of the company, be it the introduction of devops or the transition to flexible development methodologies, all participants in the process are required: from development teams to top management. This is where most of the problems arise, because people do not want to change and change something in their work. In the team, I began to listen more often to how other participants respond to our process, how they interact with other teams and stand administrators. Ideally, I would like to see some kind of end-to-end team, whose members will come up with solutions to problems, share experiences and give ideas to each other on a regular basis, but this is a completely different story.
Do you think it is necessary to go to conferences at all or is it more productive to concentrate in the office on your work?
Nevertheless, conferences are useful, and participation in them allows you to share knowledge and find out what breathes and in which direction the industry is moving. And if the conference is held in another city or country, it is also a great reason to see the world. The main thing is that participation does not become an “academic tourism” sponsored by the employer.
We told about the history and culture of the process in past articles, and today, under the cut, my story about how one trip can change the outlook or, at least, leave a mark in DevOps pioneer soul.
Going on the road
As an application developer, at the time of the trip, I had experience in pilot implementation of DevOps practices in projects, and I understood which processes were built well and which I would like to improve.
')
Surely you ask why I decided to publish when several months have passed since the date of the trip: the story below is not about tourist adventures and excursions in Munich, but what happened in the bottom line. It takes time to settle and test.
Airport, Munich, Conference
Munich is the IT capital of Germany, this is due to the fact that a large number of IT companies are concentrated in the city. The city was met with silence, and the upcoming DevOpsCon 2017 conference, in the program of which more than 45 reports were announced, inspired the joyful expectations of live communication with the leaders of the movement.
The first day
The first day of my participation in the conference was Russel Miles with the theme “Better software development systems through stress”. Speech was a kind of greeting for the assembled engineers who were skeptical, who thought that "Devops are toys, but in real-life development is a bit more complicated."
Charismatic Russel with a non-standard approach was able to entice skeptics, playing the guitar and singing the song, skillfully presenting information and inserting partly humorous theses, such as Production hates you! “Failure is EVERYWHERE!” and the introduction of applications in chaos, without receiving unexpected problems and critical errors. Utopian, but I really liked it.
Russel Miles at one of his performances, Break with Networking
Maneuvering between the halls, I lingered on a speech by Roland Huss, a Red Hat software engineer working on fabric8, a microservice platform for Kubernetes and OpenShift. The theme of his speech was: "Become a Cloud-native: Java development." I hooked up a few interesting approaches that make the transition from traditional Java development to microservice using kubernetes less painful or even painless. Roland told about the main selected environment creation tools: docker, kubernetes, fabric8, how it all interacts with each other, as well as how to put together a mini-cluster to practice working with microservices and creating infrastructure. The speech turned out to be entertaining: first, he told about the basics, and then, before our eyes, he wrote a simple application, created a docker image, set up the environment, and deployed the written application.
I want to cite several theses from the speech of Andre Neubauer and Thomas Uebel, who spoke with the topic: “Implementing DevOps strategies in DevOps averse environment”. For me, these simple but important points for awareness and perception of the problems of implementation and DevOps:
• an attempt to isolate or hire a devops man who will solve the problems of one and all;
• desire to automate everything and everyone;
• desire only to automate;
• attempt to transfer the competence of the operation to the design and abandon
The thesis voiced by the speakers is very close to me, for them DevOps is first of all a different way of thinking from the usual way, a short feedback loop due to the small iterative increment, as well as “the next logical step in the long journey called“ Agile ”. All in essence.
At the conference there were many stands of such companies as Atlassian, Appdynamics, Cyberark and others. Most of them provide services and facilities for creating a platform, organizing infrastructure, monitoring the network and others, but there are representatives of companies that help with the transformation and transition to more efficient development. Most of all, I was interested in the guys from Appdynamics, who demonstrated their own development - a system for monitoring a complex of applications. We reproduced the negative case in their application, unaccounted for by the developers, and then we were able to track which nodes walked our request, how long it was processed and on which line of code in which class NullPointerException occurred. Very useful stuff! In my work, I came across problems of defect detection: the same scenario, a set of screen forms can be developed by several teams. It was then that such a system would be very useful to me for monitoring.
Colleagues from AppDynamics
Separately it is worthwhile to dwell on the Atlassian company, whose products are used by many large customers all over the world. In my practice, Confluence and Jira, which help synchronize the work of teams. This is a single information field where the entire knowledge base of work rules and technologies, participants and products is stored. We use this platform to discuss the changes made, gather ideas and publish news.
Confluence has a set of tools that are of great help in DevOps processes:
- Project posters that allow you to “see the forest behind the trees” or in other words provide a holistic and unambiguous idea for all of the global design;
- Planning tools, with the help of which it is possible to create a project roadmap, track statuses and deadlines;
- Pages of the retrospective and analysis of incidents;
- Monitoring functionality, especially relevant in pilots and experiments;
- Numerous features for wiki, news publishing and blogging.
The speech of Christian Koch “Deployment pipelines in the enterprise” was especially useful for those who work with large enterprises. Christian highlighted the main problems faced by large companies when trying to speed up the delivery of new features to the industrial environment, and then showed how to achieve the goal. One of the main ways is to create a working environment in which there will be a fairly high level of automation - tests, assemblies, analysis. This will allow not to waste time on manual labor, but at the same time in time to “remove from the conveyor” an assembly with a bug or an idle configuration. Thus, each company has only to define its own set of tools that will help ensure quick delivery of the working assemblies and at the same time will not allow anything to break.
This is exactly how Christian sees the abstract toolkit, which will speed up the frequency of releases.
Drinks, talks and casino
The key value of any conference is networking. I took the opportunity to clarify for myself a few points that I had been thinking about for a long time. For example, find out whether representatives of companies that have long been involved in automation and work on flexible methodologies can safely say that they are “in DevOps” or “in Agile”? As expected, none of my interlocutors dared say so. Everywhere there were some "but" or "if", and some said that they only think about how to measure how devops & agile they are. For the rest of the evening, we talked about optimization, automation, and other aspects of "applying common sense to engineering." This is the combination I heard more than once from my interlocutors, while we were trying to figure out what DevOps and Agile are. But I was especially surprised by the engineer who drew an analogy between devops and beer fermentation.
How do you think there is something in common in these completely unrelated processes?
By the way, the topic of agile & devops was relevant - it was continued by Ovidiu Pitic, the head of Agile practices in Europe at Cognizant in his “Fueling Digital Transformation with DevOps” presentation.
I admit that this presentation was liked more than others: it appeals when the company, when making any serious decision, from young to old, every employee was guided by honest, basic principles of Agile. It doesn’t look like “worship” or “elevation” of Agile, it’s rather similar to the fact that they “accepted” these rules and principles, and everyone determined for himself why he followed them.
Second day
When the first enthusiasm subsided a bit, there appeared a craving for unhurried reflection, savoring new ideas and the information received. In this regard, the format of the Philipp Garbe report on “is Platform Engineering is the new Ops?” Was very successful.
He began his speech with a quote:
Philipp told how they first moved away from the separated development and testing teams, then identified the DevOps engineers, what problems they faced and how they came to the organization of engineering teams that are fully responsible for both the development and the operation of applications. The main message of the speech, as I understood for myself, is the selection of two types of engineering teams: platform and product. The former provide a functional and reliable environment so that the latter can quickly and safely deliver new features to users and receive structured feedback. It seems to me that this approach makes sense, especially if an application implies a whole software complex, and the complexity of the system environment is quite high.
Speech by Michiel Rook, Java consultant, PHP, Scala from the Netherlands, with the report "Database Schema Migrations with Zero Downtime", was a bit boring for me. The speaker enthusiastically and in front of the amazed public confirmed the conjecture that with database migrations, everything is simple if you do not use databases. This presentation was not a colossal discovery, since we do not use the database update scheme indicated below.
Michiel described a number of rules, resorting to which you can reduce downtime during database migrations. For example, the use of a load balancer to be able to disable one of the nodes on which the application is installed to install updates.
He also mentioned that in order to facilitate work with databases and reduce errors, it would be good to:
1) “break the link” between database migration and software deployment;
2) maintain backward compatibility and only expand interaction contracts;
3) to abandon destructive changes;
4) use feature toggle when working with data. For example, to remove old, replaced with new table fields.
Well, there is always something to learn.
But the Atlassian Tony Grout talk on “DevOps teams and the future backward” was entertaining. In his speech, he focused on how the principle of “openness” helps teams to achieve goals, while avoiding mistakes and not losing details. He demonstrated how teams can make decisions, experiment, try and learn, and how such an approach enhances the return of teams. We also discussed the problems of large corporations working with teams: the inability to work remotely due to security restrictions, the slow development of teams due to the lack of a culture of cooperation between different departments. Tony, I think, is convinced that today there are no restrictions for the remote work of employees and for the organization of inter-team training, that is, the creation of a “culture of cooperation”, as there are a huge number of technical utilities for effective team interaction.
The main principles of the approach:
- experiment, thereby improving the quality of the supplied functionality;
- invest in future quality, maximize automation of the pipeline for the greatest throughput of your infrastructure;
- Regularly solve urgent problems, so you will speed up the delivery of new features to customers.
At the end of the speech, Tony uttered a phrase that inspired me: “Be the change you seek“.
In the dry residue
Initially, I thought that DevOps was about automation, scripts. A fairly common misconception, as I later learned and understood, plunging into the process and on Wednesday all the deeper: DevOps implies not only a certain technical warehouse, but also a psychological one, it is closely associated with flexible development methodologies. Participation in this conference allowed me to sort out and build the knowledge in my head into a coherent picture.
Cases, insights and networking excite an inquiring mind, and perhaps even provoke an internal philosopher - DevOps is the mindset of every participant: from business and stakeholders to implementers. You can’t just take it and bring it to the company by hiring a certain type of engineers, managers or transformers. Devops goes hand in hand with Agile. This is what you need to cultivate, instill, experimenting long and hard. The way of thinking is worth changing not only in terms of software development, but also in terms of customer interaction, feedback, and removal of metrics.
Of course, you cannot go far without engineering culture: while some guys will tirelessly find defects and flaws, repair them, others will produce new functionality, not really worrying about whether their methods are optimally written and whether they will correctly handle negative cases during the testing, There are no small iteration cycles. Do not forget about automation, the high level of which will significantly reduce the time for the withdrawal of new functionality in production, and this is probably one of the weak points of many companies today.
In the wonderful book The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, the “three ways” approach is described. The first way calls to focus on the performance of the whole system, rather than its individual components. Following the second path means building a short feedback loop, which will allow you to hear and understand all the customers of the system and react correctly to their feedback. The third way is to create a culture of experimentation and hone skills. When we try something new, it will require taking certain risks and setbacks, but it will allow us to develop and become better, and the next time, in an unpleasant situation, we will know for sure how to get out of it.
It seems to me that these three principles best describe the DevOps culture to which we all strive, however, some principles of the banking system, their current organization and worldview of some people do not allow these principles to be followed to the necessary degree. I think the point is also that DevOps is a relatively young direction, because of this people have a skeptical attitude, and sometimes, when trying to apply this methodology, there are more questions than answers
I like the approach of the cognizant company, which really “flexibly” approached the matter, but at the same time did not lose as “quality”: DevOps for them is not the goal itself or even the tool for solving certain tasks, rather it is a certain way, passing on which they will be able to constantly develop and provide users with the best products.
Devops is a unique practice of learning and experimenting, where something new is always welcome. Without mistakes, nowhere, but in this case, mistakes are what drives forward, they should not scare, demoralize, they should be learned and draw conclusions. After the conference, I deployed my approach 90 degrees, because I was convinced that in such matters as the transformation of the company, be it the introduction of devops or the transition to flexible development methodologies, all participants in the process are required: from development teams to top management. This is where most of the problems arise, because people do not want to change and change something in their work. In the team, I began to listen more often to how other participants respond to our process, how they interact with other teams and stand administrators. Ideally, I would like to see some kind of end-to-end team, whose members will come up with solutions to problems, share experiences and give ideas to each other on a regular basis, but this is a completely different story.
Do you think it is necessary to go to conferences at all or is it more productive to concentrate in the office on your work?
Source: https://habr.com/ru/post/355024/
All Articles