“Faster, more frequent and more reliable deliveries”. These are the promises of DevOps; but is your organization ready to make the changes needed to achieve it?
Here a some examples of changes your organization will need to make to get the most out of your DevOps initiative.
Are your applications sufficiently decoupled and autonomous to evolve easily? Monolithic applications are difficult to modify, test and deploy. That is why microservices are the architecture of choice for DevOps. Without complete reengineering of your existing applications in microservices, it would be interesting to start now to break them into smaller segments to simplify their lifecycle (evolution and operation).
Are your applications compatible with cloud computing? Volativity of servers in a PaaS can cause data loss with stateful applications. You will need to fix your applications to avoid local logging, writing data and client session information to system files and so on. The 12 Factor App methodology can serve as an excellent guide to ensure that your applications are running smoothly in the cloud.
Having a continuous integration orchestrator (eg Jenkins) is not enough to merge frequently the branches created by the development teams.
Developers should make sure to commit their local changes one at time to the source control system . Are the database schema changes incorporated into the continuous integration process? Do the developers wait too long in their development branches before committing to the main trunk? Is the coverage of unit tests sufficient?
If you answer no to one or more of these questions, be aware that the different automation mechanisms provided by DevOps tools will be of little value. You will need to correct these situations before moving forward in your transformation, at the risk of not achieving the objectives, which are to deliver faster, more often and more reliably.
Test automation is probably the Achilles’ heel of most organizations. In fact, the organic growth of legacy systems has meant that these monolithic applications have thousands or even millions of lines of code that have always been manually tested. In order to optimize DevOps, organizations must imperatively carry out unitary, integrated, functional and non-functional tests (security, load test, etc.) This task can represent a considerable investment whose benefit will be felt only in the medium and long term. Test automation is directly related to the continuous deliveries. If tests are performed manually, the entire continuous delivery pipeline will be slowed down.
Are your database migrations automated? Do your DBAs have a perfect command of migration scripts and are these managed using versions? Are rollback procedures tested and functional? In the automation offered by DevOps, database updates must follow those made by applications to meet the objectives of continuous delivery.
Analysis of Customer Needs
If you want to go for a microservice architecture, you will need to make sure that your business analysts are proficient in modeling based on business capabilities. To achieve this, methods of analysis such as “Domain-Driven-Design” facilitate this modeling. Your analysts will have to be experienced with these techniques, otherwise the cutting of microservices will be inadequate (high coupling).
Delivery Team Structure
(from Project to Product Management)
Your teams will have to be organized according to a product management model and they will be responsible of all the stages of delivery (design and operation). A product owner will be responsible for establishing the vision. Organizations must therefore consider funding no longer by project but by product.
A culture of valuing collective success, collaboration and shared responsibility is at the root DevOps practices.
It is essential to align the motivations and goals between these teams to build trust and a spirit of collaboration. For example, teams aligned and actively collaborating within a single project and collectively assessed on all aspects of its success are more likely to be committed to working effectively together, rather than being shared. Although easy to buy, tooling alone does not provide the benefits of a DevOps practice. Technologies must be used within a cultural philosophy rooted in collaboration and joint responsibility.
The creation of sustainable teams responsible for one or more products facilitates the alignment to these objectives. The team will then be responsible for the design to the operation of their applications: “you build it, you run it”.
These are just a few examples of the technical, organizational and cultural points of view that companies must tackle eventually in order to facilitate their transformation to DevOps.
The challenge in this transformation is to accelerate its adoption with a minimum of risk. This is where our strategic expertise can help you. In fact, our experienced team can assist you in every step of this transformation: using our DevOps readiness assessment grid, we can identify which disciplines your organization should focus on to design a realistic action plan. We can also assist you in the design of microservices, test automation, building of delivery pipelines, selection of your PaaS and IaaS as well as monitoring and alerting of your applications and infrastructures.