Software News Sites: Software architecture in DevOps – – iMasters

A new book written by Len Bass, Ingo Weber and Liming Zhu, called DevOps: Perspective of a Software Architect “, part of the SEI Series in Software Engineering, looks at how the DevOps affects architectural decisions, and . role of a software architect in this universe

The authors focus on the DevOps objectives: send software to production as quickly as possible, minimizing the risk, time-to-market and the balance of such securities by the quality .

DevOps is a set of practices designed to reduce the time between sending a change to a system and its release to manufacturing in a very short term, while at the same . time high quality

These fundamental practices are:

Engaging in operations as a customer and partner, where “one party is first class “in development. Understand and meet the requirements for implementation, registration, monitoring and security in the development of an application.
Engage developers in incident handling. Developers are taking responsibility for your code, making sure that it is working properly, helping (and often assuming the role of first responders) to investigate and resolve problems in production. This includes the role of a “reliability engineer” in each development team, someone who is responsible for coordinating changes and adjustments to operations, to ensure that changes are successfully implemented.
Ensure that all code changes and configurations are made using automated, traceable and repeatable mechanisms -. as a deployment pipeline
Continuous Deployment check-in for production changes to maximize the speed of delivery, using these conduct.
Infrastructure as code. Provisioning and configuration operations through software, using the same types of quality control practices (versioning, comments, essays) and application software.

Culture and collaboration between developers and operations, shared values and organizational issues, the softer side of DevOps, are considered only insofar as they are factors that can affect the speed or quality time-to-market delivery.

As a reference to the architects, the book focuses on architectural considerations for DevOps. He discusses how cloud-based systems work, virtualization concepts and especially micro-services.

While DevOps does not necessarily require major architectural changes, the authors argue that most organizations adopt DevOps think an approach based microsserviços, and Amazon as Pioneer are Netflix, minimize the dependencies between different parts of the system and among different teams, and this will also minimize the time required for changes in production. – the first step of DevOps

The law of Conway also comes into play here. Work on DevOps is usually done by small multifunction agile teams solving problems end-to-end independently, which means that they will naturally end up building services for small and independent companies:

Having a composite of small services architecture is a response to have small teams.

But there are disadvantages and costs in a microsserviços based approach.

As Martin Fowler and James Lewis point out, the microsserviços introduce many more points of failure. This means that the resilience has to be designed and built for each service. Services can not trust their customers or other external services. You need to add defensive verification data and anticipate failures of other services, implementing times and retries, and let it go or alternative safety standard behaviors if other services are not available. You need to provide their service to minimize the impact of the failure of other services, and to make it easier and faster recover or reset if necessary.

The microsserviços also increase the cost and complexity of the system test end-to-end. The runtime, performance and latency are degraded due to the overhead of remote calls. And the monitoring and troubleshooting production can be much more complicated, since a single action often involves many working together microsserviços (an example is LinkedIn, in which a single user request may trigger a chain of up to 70 services).

In DevOps, monitoring becomes a more important factor than architecture and design in order to meet operations requirements.

The chapter on monitoring explains you need to monitor your environment and why, bringing DevOps metrics, challenges in monitoring under continuous change systems, monitoring and tracking of microsserviços cloud, common log management and monitoring tools for online systems.

Monitoring also becomes an important part of live tests on DevOps (Monitoring and Testing) and plays a key role in the continuous deployment. The authors look for common live test types, including canaries, A / B testing and the famous Army Simio Netflix in terms of passive scan (Chaos Monkey, Monkey Compliance) test and live asset (Chaos Monkey and Monkey Latency).

Security is another important cross-cutting concern in software architecture discussed in the book. He looks at the security basics, including how to identify threats (using Microsoft’s STRIDE model) and the resources that need to be protected, CIA, identity management and access controls. It provides an overview of the security controls in NIST 800-53, and common security issues with VMs and cloud architectures (specifically AWS).

In DevOps, security needs to be connected to the continuous deployment :.

By imposing that all changes to the code and configuration is done through continuous deployment
Security testing should be included in different stages of continuous deployment phase.
Protecting the product itself, including logs and other artifacts, and performing security checks that need to be part of monitoring (as Monkey Monkey Compliance and Security Netflix).

Developers – and architects – have to take responsibility for building their testing and deployment of automated testing routes. The book explains how the continued deployment takes advantage of the seamless integration and shows common approaches to code management and test automation. He also emphasizes the role of deployment along the access rules – manual or automatic controls decisions at different points to determine if it is ok to move on from development testing to stage production tests and then send the final code for the production.

The book does a good job explaining the common DevOps practices, especially on continuous deployment in a development, rather than in the context of operations. It also looks at contemporary issues in software architecture, including virtualization and microsserviços.

It is less academic than the other book Bass, “Software Architecture in Practice,” and emphasizes the importance of the world operations real and relative reliability, security and transparency (monitoring and live control tests) in architecture and implementation.

This is a book written primarily for enterprise software architects and managers who want to understand more about DevOps, continuous settlement and its cloud services.

If you are already a DevOps professional and works with microsserviços cloud probably will not find anything very new here.

But if you are researching how to apply DevOps scale, or how to migrate corporate legacy systems to microsserviços in the cloud, or if you’re a developer who wants to understand the operations in which the DevOps can improve their work, this book is definitely worth reading.

***

Jim Bird is part of the team of international iMasters columnists. The translation of the article is made by writing iMasters, with permission of the author, and you can follow the article in English on the link: http://swreflections.blogspot.com.br/2015/06/software-architecture-in-devops. html