Back in the good old ’90s, companies performed in a traditional way. They had two main technical teams – the developers and IT operation staff – to do all the work. The devs build and code the software and applications, then the ops install and maintain the servers, and test the code. Well, a rather corporate way of doing business.
Finding Nemo was way easier than diagnosing a problem between the two teams. The separate IT universes generally were minding their own processes and had no touchpoints. When the operation folks received the delivery, a classic plot twist happened: devs tested the codes in their own environment and now it didn’t match with the operational environment. So the system was crying out for change.
This is when DevOps enters the picture. In 2005 J. W. Goerlich joined the Midwestern financial services company where he initiated some first serious changes. Goerlich became a bridge for devs, operations, and attorneys, trying to unify them all and making sure that all the processes follow the law. And so it worked. Software delivery became faster, deployment nightmares were reduced, finding the bottlenecks became a simplified routine. This is how the DevOps revolution started creating quite a buzz in the IT and finance industry all around the world.
Why All the Fuss?
It seems like everyone today is discussing DevOps. But are we speaking of the same thing? Well, there’s still no strict definition of it. DevOps is more of a cultural philosophy, an orchestra of tools and practices led by a skilled conductor. And it’s evolving on the way, so it’s quite a time to be alive. According to the pioneer himself, one of the most important things was getting away from the mindset of software projects as ever being completed. Instead, they are as ongoing processes that continue long after an application has been delivered to the user. Goerlich says, “It’s as fundamental a shift in the way build technology as it was when we went from a hunter-gathering society to a farmer society. We stop viewing as a one-and-done and think of it as a series of cycles over the entire lifecycle.”
So consider this phenomenon as a modernization of the IT factory. Since today there aren’t only devs and ops, but more and more other teams enter the game – designers, managers, QA, legal department – they all must be in sync to reach the ultimate goal. Removing the barriers between siloed teams brings so many capacities and power and this is in essence what DevOps is all about. And the sky’s the limit from here.
Best DevOps Practices
Faster delivery, comradeship in the workplace and happy customers. How to reach that? Let’s check some DevOps practices that help a lot.
Oh, it’s pure awesomeness. Say goodbye to long and tense integrations. Continuous Integration (CI) is a development practice where developers integrate code into a shared repository frequently, preferably several times a day. Each integration can then be verified by an automated build and automated tests.
- The CI process is comprised of automatic tools that assert the new code’s correctness before integration.
- A source code version control system is the crux of the CI process.
- The key goal is to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.
In essence, it’s the practice of releasing every good build to users. Continuous Deployment (CD) checks that any code commit that passes the automated testing phase is automatically released into the production environment, making changes that are visible to the software’s users.
- Uses automated testing to validate if changes to a codebase are correct and stable for immediate autonomous deployment to a production environment.
- Refers to the release into the production of software that passes the automated tests.
- When Continuous Delivery is implemented properly, developers will always have a deployment-ready build artifact that has passed through a standardized test process.
DevOps practices reinforce the idea of breaking large problems into smaller pieces and tackling them one at a time as a team. The microservices is a design approach to build a single application as a set of small services.
- Each service runs in its process and communicates with other services through a well-defined interface using a lightweight mechanism, typically an HTTP-based application programming interface (API).
- It can readily scale up or down without impacting resource allocations for the rest of the system.
- Instead of creating a massive, complex beast of a program, the microservice architectural style promotes the creation of a single application in the form of a suite of smaller services that each run their own processes.
Infrastructure as Code
Manual tasks result in mistakes. Our memories fault us. Communication is hard, and we are pretty bad at it. Infrastructure as code means to manage your IT infrastructure using configuration files.
- It provides speed. IaC enables you to quickly set up your complete infrastructure by running a script. You can do that for every environment, from development to production, passing through staging, QA, and more.
- You have full traceability of the changes each configuration suffered. No more guessing games about who did what and when.
- By employing IaC, you can deploy your infrastructure architectures in many stages. That makes the whole software development life cycle more efficient, raising the team’s productivity to new levels.
We need to know what we did yesterday, what we are doing today, and what we will be doing in the future. Also, to understand the reasons behind our actions (in real life it’s not that simple). But this is how we can move forward. Configuration Management (CM) ensures that we are making informed business decisions and performing the right actions.
- An important function is defining the state of each system. By orchestrating these processes with a platform, organizations can make sure there’s consistency across integrated systems.
- It leads the process of finding and cataloging system-wide configuration needs.
- If over the time your configuration needs change, and configuration control allows this to happen in a controlled way as to not destabilize the existing infrastructure.
Policy as Code
In a nutshell, Policy as Code is the idea of writing code in a high-level language to manage and automate policies.
- By representing policies as code in text files, proven software development best practices can be adopted such as version control, automated testing, and automated deployment.
- The information and logic about a policy is directly represented in code and can be augmented with comments rather than folks retelling to each other to learn about the reason for policies.
Monitoring and Logging
Together these two make more pure awesomeness. Logging generates a detailed set of events that occur within your application, while error monitoring tells you if your application is working. So combined, monitoring your applications and logging their data help you keep your customers super happy.
- Monitoring provides feedback from production about an application’s performance and usage patterns.
- Logging and monitoring work best together. As the systems keep getting more complex, doing either one alone is not enough.
- It creates a smoother user experience and reduces the need to fight fires after the application is live in production.
Communication and Collaboration
DevOps is a synonym itself for comradeship and knocks down corporate walls between teams. In spirit of togetherness we trust!
- Information sharing and speeding up communication across developers, operations, and even other teams like marketing or sales through the use of chat apps, wikis, other systems.
- Less “That’s not my job” situations. In the devs world this practice is often called “throwing it over the wall,” and it’s characterized by creating or encountering a problem, then passing it to another department.
- Tech proficiency shouldn’t be placed above collaboration and communication but treated of equal importance.
How DevOps Works
Let’s stick to the industrialized factory example and explore this phenomenon in easy terms.
Now, before the craziness of Cyber Monday and Black Friday, manufacturers (devs) must be ready for the siege. So every step must be calculated and thought through twice for faster product development.
First things first, the owner of such a modern facility gathers all the materials that are needed for the production (Continuous Integration/Continuous Delivery). Next, he’ll make sure the stuff is thoroughly sorted and tagged. To make the manufacturing process faster and more burden-free (the goal is clear – more products at a fast pace), the board decides it’s time to add some upgrades to the tech part to speed up the production (Infrastructure as code).
Here starts the beautiful dance of conveyors, while their belts heave the materials here and there across the factory on many tracks being touched by different experts. Until voila – the final masterpiece is finished (Continuous Integration). Before going to the stores, be it Target, the products are tested and wrapped (Continuous Delivery) in the end.
Oh boy, but what if the goods are found to be defective? Detecting flaws becomes easier with the new practices. First of all, since the staff is trained to use a super convenient system for task management and communication (Communication and Collaboration), it becomes easier to collaborate in this dark hour.
Then, the team is using the Master Control Panel (Continuous Integration), tagging system, other monitoring panels to know all about the efficiency, machine functioning and the performance of the finished goods (Monitoring, Application performance management) and to monitor all the processes going on at the moment (more complex product, bigger team, upgraded tech, etc.). So finding what’s causing a headache becomes a piece of cake. They quickly solve the prob. And apparently, get Christmas bonuses.