DevOps is a methodology of iterative software development that embraces close collaboration between contributing software developers, QA and IT operations staff.
When fully embraced, there are many valuable attributes to this iterative style of development including:
- (much) shorter release cycles
- increased productivity
- faster time to market
- less intrusive upgrades
- and higher quality software that will in turn increase the satisfaction of your customers.
With DevOps, you need to deploy infrastructure and applications rapidly, treating them both as code and having that code base be deployable at any point in a verifiable (testable and repeatable) way. Meaning they can be deployed wherever you want - whether it’s at the data center, in the cloud, or between multiple environments. You’ll also need the ability to make any changes to that code base in a safe and controlled manner that isn’t going to break things along the way or have unintended consequences.
Self-Service Provisioning for DevOps
A key DevOps principle is to develop and test on environments that mimic a production environment. Any mismatches in the environment such as simple differences in the configuration at either the operating system (OS) or middleware level can introduce significant quality issues. These issues arise because developers are unable to verify how the application would behave in the production environment, or if it can be even deployed to production through the processes used for deployment in the test environments.
Requesting an environment that mimics the production environment for an on-premise infrastructure through a formal ticketing process can take days if not weeks to fulfill. And as the ticket is processed, the environment may have changed, and this again creates bottlenecks in the delivery pipeline, preventing the software development cycle from being efficient and lean.
Utilizing a cloud infrastructure combined with automation for DevOps teams addresses these problems. How? By enabling them with self-service provisioning and on-demand environment availability along with access that allows systems to be dynamically provisioned and de-provisioned as needed. This reduces the need and associated costs of permanent, static test environments.
Full stack automation is another key component of a DevOps practice. It provides the means to deploy a cloud application and configure the cloud environment on which it runs. This means automating the provisioning and the correct versions of the configurations of the Server, Network, and Hosting Environment, middleware layers, and applications to these environments. Automation ensures that the correct systems are available as and when needed so they match the production systems that the developed applications will eventually reside on.
You can achieve this automation using a tool that enables the creation of templates or “blueprints”. These capture the definition of the environment and then map application components and configurations to deliver a fully configured system.
Deployment automation tools such as Embotics vCommander can deliver full-stack provisioning using blueprints. Post-deployment, further application, configuration, and content changes can be continuously deployed to the cloud environment as required to keep the systems current.
DevOps goes far beyond just the concepts of cloud and automation. This is especially true for larger organizations or any organization that has matured past the point of startup and is adopting the concept of governance.
Governance for DevOps teams may not be governance in the traditional sense, but in DevOps there’s a large amount of open, collaborative workloads, shared code, and contributions from others that may be in other business units or not directly in the development or testing teams. Good services make for good neighbors, and the concept of governance, especially in larger organizations, is what really allows organizations to be able to open up the work load and change the way that collaboration works across teams.
Some of the common challenges seen in a dynamic development environment include:
- Manual processes.
- Knowledge transfer between teams.
- Quick or short paths to accomplishing tasks such as hardcoding credentials in code.
- Cost management such as with controlling the type of instances being provisioned.
Controls need to be put in place for any high-risk actions. Once these are in place, there needs to be subsequent monitoring of the environment to ensure that resources are correctly configured. This monitoring will then allow you to expose any issues and resolve them in a timely manner. As a final step, audit reports need to be created to show that compliance is being adhered to throughout the process.
An automated provisioning and orchestration tool can mitigate the manual processes, reducing human error throughout the provisioning process. It can also provide cost management tools and auditing capabilities that are required for accountability.
Almost directly related to governance is culture. If the first three pillars are taken care of, but you don’t have the culture right you’re probably not going to succeed with DevOps.
Building a culture isn’t like adopting a process or a tool and can be challenging and difficult. It requires the leadership and encouragement of teams of people, each with unique skills, experiences, and biases.
A successful DevOps culture is defined by the work spaces that are created for them. Leadership needs to eliminate the fear of punishment or failure and ensure that they place high-value on learning through experimentation and collaboration across roles, focusing on business instead of departmental objectives. This in turn leads to a high-degree of trust within and between the teams.
And these teams must know why they can experiment safely: because there are practices in place that ensure rolled out experiments are easily and rapidly fixed if need be. They also need to be aware that they must provide visibility into what’s happening and that their focus on work load has ramifications in terms of how communications and collaboration between departments occurs.
Transitioning to a DevOps culture, requires culture change in the IT organization and very often the rest of the organization as well. Encouraging teams to be more multidisciplinary and cross-silo is the goal. Before changing to a DevOps culture, there may have been silos of Dev, test and IT, and within IT there can also be the silos of storage, networking and security as well as others. In in order to achieve the goals of automation and agility, you need to break down those silos and change the culture of your entire organization to be a much more agile and inclusive.
If you can do that then you can be successful in this journey.
Software tools can of course help in with a culture change, but it’s not the tools that actually help create the culture, it’s the behaviors that those tools enable. While you can't directly change culture, you can change behavior. The tool that you choose may enforce certain behavior, and that behavior will become your company culture. And so, it's important to look at the workflows that were being enabled out-of-the-box by the tools you choose.
By providing automation tools, you can configure a self-service that shows the options for what can be on the stack and enables people to move without having some of the cultural roadblocks that might have existed previously.
DevOps as a Maturity Curve
The DevOps journey is more of a maturity curve. There are key behaviors and patterns that need to be seen in an organization to know that it’s safe to move at the velocity of continuous deployment. What set of practices do you have down pat? Do you know when you’re experimenting? When you’re releasing changes out to market quickly, are you putting the business at risk?
When talking about managing infrastructure as code, the development life cycle practices that might be established in applications development may not be there in infrastructure management. One of the patterns for success is making sure that you know exactly how you’re moving from making changes on a local development environment, what the practices are that you’re going through to test your code, and making sure that they’re consumable by the rest of the organization. This means looking closely at how you collaborate with other teams, share code, structure code, how repositories are opened, and the communications mechanism between teams. You need to know as an organization what’s happening as various code is added that’s contributing to the same code base.
The next step is looking at continuous integration patterns. You need to look at how those changes are taken and collaborated on with others to get them merged into the code and always have a reversible state that encourages short-lived branches. You also need to look at the types of testing being carried out in order to make sure you’re not breaking the code trunk or master. And once you accept and merge those core changes, you need to be certain that it’s the right thing to do.
Once the code is in a deployable state, you then need to look at how an artifact can be generated and stored so that the rest of the infrastructure can consume it. Once you know that these practices are solid then, you have a foundation for full stack automation. You can be sure that all of the code that is being contributed is actually reflecting applications running in production.
So, DevOps is really about looking at the entire life cycle management of your applications. How do you go from development to test, to QA, all the way up to production? What is the right level of testing you need to do at all these stages? What is the right way to ensure that most environments are exactly where they need to be? If you can define requirements and ensure they will all flow together, then you’re ready to look at the pipeline that can be automated and get your code all the way from local development out to production in a faster, viable, safe, repeatable manner. That’s the DevOps process in a nutshell.
If you’re interested in hearing about how Embotics can help you move up the DevOps Maturity Curve, you can get in touch here.