Five Principles of DevOps

4 min readJan 11, 2022

This article summaries some core concepts of applying DevOps. AWS technologies and experiences would be taken as examples, to illustrate these concepts. Let’s start with the following five principles:

№1: Performing Frequent but Small Updates

№2: Adopting Microservice Architecture

№3: Infrastructure Automation

№4: Continuous Integration and Continuous Delivery

№5: Logging and Monitoring

Principle I: Performing Frequent but Small Updates

One fundamental practice is to perform very frequent but small updates. This is how organizations innovate faster for their customers. These updates are usually more incremental in nature than the occasional updates performed under traditional release practices.

Frequent but small updates make each deployment less risky. They help teams address bugs faster because teams can identify the last deployment that caused the error. Although the size of updates will vary, organizations using a DevOps model deploy updates much more often than organizations using traditional software development practices.

Principle II: Adopting Microservice Architecture

What’s Microservice Architecture?

The microservice architecture decouples large, complex systems into simple, independent projects. Applications are broken into many individual components (services) with each service scoped to a single purpose or function and operated independently of its peer services and the application as a whole.

Why Microservice Architecture?

Organizations might also use a microservices architecture to make their applications more flexible and enable quicker innovation. This architecture reduces the coordination overhead of updating applications, and when each service is paired with small, agile teams who take ownership of each service, organizations can move more quickly.

The traditional development cycle always takes longer time to deploy new updates because project teams need to make sure the integrations between various components working well with the new update in the complex “monolith” application. The situation becomes even worse when the application involves more team collaboration and deploys more features / integrations.

As a result, people start thinking a new collaboration model in terms of architecture and team size. The concepts of “2-pizza team” and microservice architecture are introduced in the recent market. Each “2-pizza team” involves 5 to 7 team members, focusing on building their own microservices which work as web services / APIs. Also, each microservice works independently for a single function. The project team can make a combination of these microservices (i.e. building blocks) to build the whole application.

Principle III: Infrastructure Automation

However, there are some drawbacks of the combination of microservices and increased release frequency. It leads to significantly more deployments which can present operational challenges and risks.

On one hand, we like to increase the development agility; on the other hand, we need to implement more on Management, Control and Automation. Thus, DevOps practices like Continuous Integration CI and Continuous Delivery CD try to solve these issues and let organizations deliver rapidly in a relatively safe and reliable manner.

Furthermore, infrastructure automation practices, like Infrastructure as Code and configuration management, help to keep computing resources elastic and responsive to frequent changes.

In addition, the use of monitoring and logging helps engineers track the performance of applications and infrastructure so they can react quickly to problems.

Benefits of leveraging Infrastructure as Code:

· Scalability (anything manual is not scalable)
· Reliability
· Reproduction / Duplication
· Environment Consistency
· Auditability / Record Keeping
· Security
· Governance

Tools for Configuration Management:

· AWS CloudFormation
· Ansible
· Saltstack
· Chef
· Puppet