中文
Enterprises across the world today are becoming increasingly interested in leveraging DevOps to deliver applications and services at a fast pace. However, at most organizations, awareness of DevOps has remained confined to abstract principles rather than practical knowledge. There is a strong misunderstanding about the purpose of DevOps, and as a result many companies are far less confident in implementing agile operations on the ground.
In this post we share advice from Kevin Jones, a Global Solutions Architect at NGINX and an expert on managing DevOps environments, on successfully transitioning to DevOps.
Setting the Goals
“What are we trying to achieve? Is it to modernize our applications? To transform our infrastructure to achieve agile development?”
Those are the questions for organizations to ask about any transition towards DevOps, according to Kevin, who stresses that outlining a clear set of goals is the first step for uncertain organizations.
“I think it’s about identifying where the organization really wants to be, from a technical perspective,” Kevin explains, “but also making that match what the business is trying to do. If you’re Uber, for example, you probably have it somewhat figured out already, but there’s always a roadmap – there’s always somewhere you’re trying to get to.”
Choosing the Right DevOps Tools
One of the first decisions organizations need to make during a DevOps transformation is which tools to adopt for their new operational framework. At this stage, many organizations start by looking at which products or devices they are going to incorporate. There is an unlimited number of tools available to modern IT teams; therefore, it’s important for companies to decide which tools best match their use cases.
Before purchasing a new tool or platform, it is vital to be proactive by meticulously testing each possible choice. If monitoring has been called out as an important feature, for example, you want to make sure that the tool you select reports on all the factors you care about – response time, memory usage, requests per second, and so on. For Kevin, “the key lies in making sure that they’re gonna solve the problems for those goals that you have”. Taking the time to ask those questions about the viability of new tools allows you to make a much more informed decision about the devices you adopt.
Fostering Cross-Functional Communication
Perhaps the most challenging obstacle most organizations face when transitioning to DevOps is fostering communication between the business and technical sides. All too often companies adopt DevOps processes but not the non‑siloed organizational structure required for effective collaboration between functional teams.
“In a lot of organizations,” Kevin explains, “DevOps teams don’t necessarily have much control over what’s going on. It’s kind of like a balancing act, with the business on one side and the infrastructure and technical people on the other.” Driving communication between the business and technical side of an organization, therefore, is fundamental to the DevOps philosophy.
As Kevin highlights, “it’s really helpful to inspire discussion with these teams to make sure that the right decisions are made”. If a department or stakeholder wants to adopt a particular tool, Kevin suggests that the DevOps team needs to be included in “helping to make a decision on whether it will improve the environment by adding value and not adding unnecessary complexity to the infrastructure. There are many tools out there to adopt, but as a group, teams can make educated decisions to accomplish the overall goal”.
For most DevOps teams, internal or cross‑team communication is a challenge due to their enormous workload of production escalations, ticket backlog, and change management planning, but Kevin suggests that this cannot be an excuse for a backseat approach. “Even though DevOps teams are typically busy,” he explains, “they should make themselves available for these kinds of discussions, being involved in the business as much as possible.” Opening a dialogue between disparate teams is as much a cultural change as it is an operational one.
Measuring Success in DevOps
Like any operational methodology, DevOps is about results. Being able to identify successes and failures is essential to gathering feedback when developing new processes. Many companies, however, find it difficult to measure new processes, such as DevOps, effectively.
From Kevin’s perspective, there are three main examples of measurement: cost, modernization, and performance. “I think there are different types of results,” he adds. “We can talk about economic results: what is it that you’re trying to achieve from a financial standpoint? Maybe it’s not related to money at all. Maybe it’s tracking a migration from using legacy applications or legacy infrastructure to more modern infrastructure.”
The third possible measure of success is the performance of the application over time. For this, he suggests asking some basic questions beforehand: “Is the application performing better than it was last month, or better than it was last week? Also, what is the end‑user experience?”
Successfully achieving a goal relies on open communication and unity between the business and technical sides of a company. Collaboration is necessary to outline what results you’re looking for and the tools you plan to use to deliver them. In regular discussions with the business teams, the DevOps team can provide expert guidance throughout the transition.
Making DevOps work for your organization is about starting with a clear end goal in mind. If you have a goal to work toward, you have a reference point to help you ask the right questions. As Kevin said, DevOps “is a lot about the culture and just being involved in the business as much as possible, every step of the way”.
To find out more about how NGINX can help transform your business through a DevOps approach, get in touch.
