devopsy.kinsta.cloud

Tag: DevOps management

  • What DevOps Leadership Should Look Like

    What DevOps Leadership Should Look Like

    Implementing DevOps has become a major focus, but the practice’s attempt to provide organizational support and streamline production systems simultaneously leaves developers with no clear hierarchical structure. We know we need DevOps and we know it helps, but we also know that without proper leadership or structure, it can be misunderstood and undervalued. To build a strong collaborative culture, DevOps leadership, like most other leadership roles, requires a different type of skillset—a skillset that isn’t always prioritized in software development. The ability to understand programming languages, to be versatile and be attentive to detail will take a developer far in their career, but once they’re in a management position, what is needed to be an effective DevOps leader?

    First, what does an effective DevOps leader look like? To start, they need to lead. But to lead a DevOps team, it’s important to not only understand development—including reasonable goals and how to accomplish challenging tasks—but a DevOps leader needs to be able to create an environment that fosters collaboration between teams.

    This is why a DevOps culture is a core value for any high-performing DevOps team. This is due to the cross-functional nature of the practice. The stages of the DevOps cycle (plan, build, test, deploy and manage) rely on different teams with different skill sets.

    Build a Culture Of Ownership and Teamwork

    To effectively collaborate, a strong cross-functional culture of ownership, teamwork, intensity and smart application is needed.

    Clarity can transform a team, and it starts with ownership. Ownership is essential for cross-functional DevOps teams to understand their roles and what they are responsible for. In order for clarity to exist, leaders need to provide clear direction and guidance. It is a leader’s responsibility to set realistic goals and offer support. Group trust is built when a team has a common goal and clear roles and responsibilities are identified.

    Ownership is the foundation of teamwork, and with it, team members can see their individual contributions to a project and can celebrate their successes together. This teamwork then breeds collaboration, improved performance and a cohesive dynamic within the team’s culture.

    Lead With Strategic Intensity and Smart Application

    A DevOps leader can empower their team through ownership and teamwork, but we can’t forget the value of knowing the right level of intensity for a project. Leaders need to understand a situation, the context and how to approach it strategically to avoid burnout and bitterness. They must know when to apply intense sprints and when to pull back and move resources—a leader must know how to play smart with the resources they have.

    Use Soft Skills

    People management skills can be overlooked in a lot of leadership positions. For example, we might see it when a startup chooses a CTO or an engineering lead position based on seniority or developer skills without regard for their ability to actually manage people or their desire to be in such a position. Often, the person in charge of a DevOps team is given this role because of their previous development accomplishments, but they lack the necessary soft skills of communication, conflict management and/or teamwork. Using the four principles above can help accelerate the foundation of culture as well as help compensate for a leader’s lack of soft skills

    DevOps leaders need soft skills. Soft skills include the ability to think critically and project manage while having enough emotional intelligence to inspire, motivate and retain a team of smart engineers. Every leader needs to be able to see their team’s strengths and weaknesses, listen and influence and further develop their members to succeed. The challenge for this role is that, to be successful, it takes both technical expertise and soft skills and knowing how to balance the two.

    Unfortunately, soft skills haven’t been prioritized in the training and career development of most software engineers. Only recently have soft skills been seen as a differentiator in the engineer hiring process or seen as a value-add to an organization. For years, technical skills took precedence and we ignored the areas that would take a software engineer to the next level – the soft skills that will lead to leadership. But it’s a bigger problem; employers say most college grads aren’t learning these soft skills in school.

    Remember the Not-so-Secret Sauce

    Soft skills empower a leader to thrive both within a DevOps team and in collaboration with other departments. The ability to work across teams can exponentially improve business operations. A strong DevOps leader can offer solutions and problem solve for internal issues and customer-facing problems. They are able to bring DevOps into new areas of the company in a strategic and effective way. Collaboration requires working with others, seeing the bigger problem, understanding the business goals and using soft skills to get things done.

    It’s the not-so-secret sauce that makes all the difference when running a powerful DevOps team. A culture of collaboration starts with the leader. A leader’s relationship skills can increase the likelihood of bigger budgets, more tools and recognition. DevOps leaders can build a strong team by leveraging the soft skills within themselves and their team members, applying the right level of intensity and encouraging a culture of ownership, teamwork and collaboration. If these things are missing, whether DevOps or another team, the unit will fall apart.

    This is why a DevOps leader needs to take personal ownership and responsibility for the success of their team and see motivating others, setting a standard of operational excellence and representing the DevOps team as an integral part of their role. Luckily, there are resources to learn and exercise these skills so every leader, newly appointed or veteran, can ensure their team can excel.

  • Technical Debt is a Major Threat to Innovation

    Technical Debt is a Major Threat to Innovation

    A survey published today suggested that technical debt is starting to take a heavier toll as IT environments continue to become more complex to manage.

    The survey of 400 IT leaders at organizations with 1,500 employees was conducted by Foundry, the market research arm of International Data Group (IDG) on behalf of Insight Enterprises, a provider of IT services. The survey found that 86% of respondents reported their organization was impacted by technical debt over the past 12 months, with the top areas affected being the ability to innovate (43%), meet service level agreements (41%) and avoid downtime (37%).

    Technical debt is created when organizations cut corners and leave known bugs in the race to meet application delivery deadlines. Application code is often not as thoroughly tested as it should be. In some cases, it turns out that what was intended to be a minimum viable product doesn’t scale all that well. Quick fixes needed to improve performance are also frequently undocumented. Inefficient code also winds up consuming more IT infrastructure than required, which adversely impacts everything from cloud costs to the amount of carbon generated.

    Juan Orlandini, chief architect for the Cloud + Data Center Transformation (CDCT) division of Insight Enterprises, said every organization struggles with technical debt; it will never be eliminated, but it does need to be contained, he added.

    The challenge is instead of trying to keep the proverbial IT lights on during the COVID-19 era, IT teams are now being asked to innovate to advance digital business transformation initiatives, said Orlandini. A full 87% of survey respondents cited modernizing critical applications as a key success driver.

    As a result, many organizations are embracing platform engineering to bring more structure to their DevOps processes, he noted. The challenge, however, is striking a balance between a more centralized approach to DevOps and maintaining the ability of developers to innovate, said Orlandini.

    The issue, of course, is that in addition to massive technical debt, the latest generation of applications are more distributed than ever. The survey found 91% of respondents now rely on multiple public cloud providers for different workloads, with 54% of data residing on a public cloud. However, the survey also found on-premises IT environments are still relevant, with 20% planning to repatriate select public cloud workloads to an on-premises model over the next 12 months.

    Nearly three-quarters (72%) of respondents also noted data volumes are growing faster than their ability to manage them, with 64% ranking implementation of a data governance program to improve data management as their top data-related objective this year. Just over a third (35%) of the data estate is now, on average, driven by edge workloads, with 29% of respondents reporting that at least 50% of data volumes now reside on the edge. Nearly two-thirds (64%) expected that to increase in the next 12 months.

    A total of 85% of respondents also indicated their organization is using artificial intelligence (AI) to some degree to drive business insights and/or efficiencies, although only 36% reported having optimized their use of AI and machine learning (ML) across the enterprise.

    Finally, cybersecurity also remains problematic, with 51% reporting they were impacted by a cybersecurity breach over the past 12 months. Just 20% resolved their issue in one day, while 31% needed less than a week. Nearly half (49%) required one week or more to recover.

    It’s clear that IT isn’t becoming any easier to manage. IT teams need to find ways to build and deploy new applications while reducing technical debt so it doesn’t strangle future innovation.

  • The Real Pipeline

    The Real Pipeline

    I’ve made no secret of the fact that DevOps was a game-changing advance in how the business of IT was done. But people tend to get religious about the methodology and forget the point. That’s okay, DevOps has its roots in that mentality. After years of thinking bad things about the authors of The Phoenix Project for portraying anything that slows the process–you know, like code quality or security–as bad, I have come to accept that absolutes were required to drive forward motion in the market. “We’ve always done it this way!” was king in IT, but the rest of the business was fed up. That book got the ball rolling and we’ve slowly but surely pushed back against the mentality that adding milliseconds (or even a week) to build times in the average enterprise has any impact worth mentioning. Oh, some people still claim it does, but we can convincingly make the code quality/security argument.

    It is funny to me that the first few years of DevOps were focused on “We’re gonna change your religion!”—wanting to force upheaval of the entire IT org chart without a thought to the fact that you still needed specialists in storage, ops, etc. to keep the lights on. The mentality was that development issues were a people problem. To a large extent, they were right; they just missed one people problem in the set of equations. Let’s look at the real pipeline that we all don’t talk about, but really should:

    Notice there aren’t tools in this chain; instead, there are groups of people. It is sad but true that the last two–representing acceptance testing and customer rollout–are almost always merged these days in all but a few organizations.

    This isn’t controversial; we still do the dev bit largely before the ops bit; the business has to decide what we want to offer the customer and customers are at the end of the line. And that is the key. Customers are at the end of the line. Now, I get to make you uncomfortable. Nothing in the above diagram matters except the first and last arrows. Think of it like this:

    What’s important in what we do comes down to two questions: “What does the business unit want to offer customers?” and “What do the customers expect of the business unit?” In this sense, “business unit” might be IT and “customers” might be co-workers. That changes nothing. What the business unit offers and what customers want is all that matters. The rest is implementation detail.

    Don’t believe me? It is an easy case to prove. Let’s try this one, with or without IT involvement, depending upon the problem being solved and the organization:

    The business unit determines what they want to offer, customers let their demands be known (one way or another) and the business offers the solution they think fits for the customers. As I said above, the rest is implementation details.

    What is your point?

    This leads me to the inevitable observation. Testing and security are:

    • Completely expected by users. They don’t want buggy software, and they don’t want to enter information assuming it will get nicked by hackers. There is no compromise here; users don’t “kind of want a product that works” nor do they want a product that “might be secure, but we’re not sure.”
    • Desired by the business. They have constraints on what is reasonable–the old meme of a server with the network cable cut is only funny because it shows extremes. But they absolutely do want the product or service they are offering customers to be stable and secure. “We can just spin out a new version” only works so often and for so long.

    So, your toolchains need to include stability and security tools—I would argue at every step of the process, but where and how much is really a business call. My security peeps will get upset that I called security a business call, but it is. You can choose to be non-compliant and insecure; the impact of those decisions on your organization is all on you. OTOH, of all the things that the organization (both the business generally and IT specifically) are focused on, you can afford to drop a few and get security and stability right the first time.

    Meanwhile, you’re keeping things running while we debate things like this. While I repeatedly refer to a large portion of my target audience as “implementation detail,” I’m sure you all know how much I (and many others) appreciate the rockstar job you’re doing keeping the IT org supporting the greater org.

  • The DevOps Management Perception Gap

    The DevOps Management Perception Gap

    The DevOps momentum is fierce in the enterprise today, as executives and middle management recognize the transformative power that continuous delivery of software has for a business. The message that DevOps can lead directly to increased profitability for organizations has seeped into technology leadership consciousness and tech leaders are gung-ho to reap the rewards.

    The problem is that their enthusiasm isn’t necessarily translating into a meaningful enough change in leadership patterns to really optimize the benefits of DevOps. The “2018 Global Developer Report” released by GitLabs recently offers some meaningful evidence of this. Study results hint at some Pollyanna-ish attitudes by managers that potentially could be leading to them resting on their leadership laurels.

    The GitLab study showed that managers are overestimating their DevOps teams’ performance as compared to the developers who are on the ground getting the work done. While 81 percent of managers say DevOps saves time in the development process, only 65 percent of developers agreed with that statement. There was a similar disparity when it came to awareness of speed of delivery capabilities: Approximately 47 percent of managers said their organization deploys code on demand or multiple times a day while only 39 percent of developers said the same.

    This gap could point to a potential disconnect growing within leadership that’s unable to adjust their management style to DevOps’ democratization of everyday development responsibilities. The study shows that almost a third of managers admit they don’t have visibility into what others are working on.

    While individual teams do need to be given the autonomy to get work done with less red tape in the way, leaders still need to provide companywide direction and strategic supervision. In the end, teams need to come together to meet global business goals, and that’s where managers need to step in.

    “What you need your leadership to do is apply systems thinking, and that’s a whole another subject we could get into, but I don’t think executives and leaders know how to really address the, ‘How do I optimize this as a whole?’” Carmen DeArdo, technology director for Nationwide Insurance, recently told devopsy.kinsta.cloud. “You need to really focus on the strategy and make sure you’re removing barriers and allowing teams to innovate and improve your delivery capability.”

    Unfortunately, the GitLabs study proves out DeArdo’s point, showing that leaders are missing their mark in this regard. The survey showed that “unclear direction” is the top challenge named by developers in getting their work done. It was cited by 67 percent of developers as their biggest impediment.

    Meanwhile, managers may not be aware that they’re not providing proper direction. Managers are 35 percent more likely to say they set project expectations up front than developers are to say they receive such requirements right out of the gate. In fact, only half of developers agree that they receive ample expectations and requirements from the start.

    — Ericka Chickowski

  • The 7C Holistic Approach to DevOps

    The 7C Holistic Approach to DevOps

    The DevOps methodology was first adopted in 2007 with a bigger purpose of improving organizational efficiency by bridging the gap between software release and IT operations teams. This started as the core practice of continuous integration (CI) and continuous delivery (CD) with a prime focus on better quality of releases and more frequent releases. Now, DevOps is becoming the norm of the industry and is being embraced by multiple organizations as a digital transformation with a shared goal, involving all stakeholders, to serve the customers better with higher quality product release and more frequent releases.

    DevOps has evolved beyond release and deploy and now involves product owners, project managers and all aspects of software development life cycle. This is the key reason it has evolved as a holistic approach starting from the service team interacting with the customers to product release and production monitoring. In this blog, we will explain how the 7C approach of DevOps is a natural evolution of DevOps and how it helps different organizations to perform better.

    DevOps now spans across the entire organization involving customer service, marketing, product owners, project managers, program managers, and different levels of developers, QA, release or build teams and infrastructure team. As the main focus of DevOps is to serve the customer better and faster, it is important that all the stakeholders have better end-to-end visibility of operations, planning, integration, testing, monitoring, delivery and feedback. This is the 7C approach of DevOps, as illustrated in Fig 1. This requires an efficient integration of processes and tools to automate the seamless information exchange and execution. This approach also empowers all the stakeholders to better contribute in product’s success and efficient execution.

    Fig. 1: 7Cs of DevOps

    The 7C holistic approach to DevOps also requires efficient collaboration between all stakeholders, empowering them to contribute more. The 7C approach removes all silos of information and execution.

    Startups were fast to adopt DevOps as many of them were setting up things from scratch. But the latest industry trends show large enterprises embracing DevOps primarily with the focus on efficiency and better, more frequent releases.

    The DevOps domain includes lots of tools and many of them are open source. This has provided a toolset for engineers to tinker with or experiment. This tends to have problem of its own, as too many toolsets in the flow create silos of information and execution, which creates confusion and inefficiency. This is becoming a problem and that’s why solutions are required which provide better integration and execution across multiple tools. The right solution for this will be a platform with deep integration capabilities.

    A deep integration platform for DevOps will enable seamless integration and execution across different tools, even home-grown proprietary tools, to provide a holistic solution starting from customer initiation to production deployment and feedback. This approach is significantly important for large enterprises, as this enables them to have the flexibility of preserving their existing investments on tools and processes while also allowing them to selectively introduce new tools. Rather than trying everything new, large enterprises can manage changes while primarily focusing on efficiency, automation, collaboration, better quality of releases and more frequent releases.

    This 7C approach gives same visibility to all stakeholders and everyone knows what feature is being released when. This approach also helps to move information/execution in both left and right direction with powerful traceability features, analytics and dashboards. Deep integration of information and execution also reduces dependency on other teams and promotes self-service.

    Fig. 2 illustrates a sample DevOps flow where service team uses ServiceNow; software, product and project managers are using Jira for Agile management, developers are using Eclipse as their integrated development environment, GitHub is used for source code repository, QA team uses a test management tool for test and defect management, and finally the release team uses Chef and Jenkins to orchestrate build, release and deployment. In real-world examples, teams add more tools for code analysis, security and production monitoring. All such complex flows are supported within DevOps 7C holistic approach by utilizing the deep integration platform. The 7C approach is more productive as it allows faster detection, analysis and resolution of problems.

    Fig 2. Sample DevOps Flow with Deep Integration

    The 7C approach works well with both traditional waterfall software management as well as Agile software management—mainly because of better end-to-end visibility, efficiency and collaboration.

    To conclude, 7C approach of DevOps is the natural evolution of DevOps, empowering the team to achieve better efficiency and execute better. This empowers all the stakeholders in the organization by providing better end-to-end visibility and powerful means of collaboration. Involving all stakeholders also creates a better environment of trust and collaboration. With this 7C approach, DevOps is not limited to build and release but it has spanned across the entire spectrum of software development lifecycle. This is especially highly beneficial for large enterprises as it enables them to preserve their prior investments and enhance their existing flows. This gives them leverage to selectively try new tools and technology while preserving what is working well. This is a great approach to expedite the enterprise level digital transformation.

    About the Author / Devendra Joshi

    Devendra Joshi is Sr. Director, Customer Solutions and Products at Kovair. He is a software professional with over 20 years of experience in enterprise software, social media, healthcare, SaaS companies, and EDA. He has worked with startups and large enterprises in engineering management, and product and solutions management roles.

  • With Distelli Technology, Puppet Expands DevOps Portfolio

    With Distelli Technology, Puppet Expands DevOps Portfolio

    At its PuppetConf 2017 conference, Puppet made it clear its ambitions now extend well beyond its namesake IT automation framework for IT infrastructure. On the heels of acquiring Distelli in September, the company announced it is adding several products to its portfolio based on technologies developed by Distelli.

    The new offerings include Puppet Pipelines for Apps, to automate commits; Puppet Pipelines for Containers, to automate the building of Build Docker Images from a source repository and then deploying them on a Kubernetes cluster; and Puppet Container Registry, to host Docker images and unify views of them regardless of whether the repositories are local or remote.

    At the same time, the Blueshift platform developed to automate deployments of container platforms such as Kubernetes, Docker Swam and Mesos is also being enhanced. The Kubernetes module now installs the container cluster in a more secure way that is also highly available. The Docker module adds support for Puppet Code Manager, Docker Swarm mode and Docker Secrets. A Kream tool makes it easier to deploy Kubernetes and Helm, a package manager for Kubernetes, at the same time. Helm also now can manage applications deployed on Kubernetes.

    In addition, the company announced Puppet Discovery, a tool that makes it simpler to identify infrastructure distributed across a hybrid computing environment, and Puppet Tasks, which employs new open-source agentless software dubbed Puppet Bolt to automate entry-level IT tasks. Bolt is capable of running existing scripts written in any framework and executing them on any platform that Puppet supports.

    The company is also adding a Task Manager to Puppet Enterprise that makes it easier to manage ad hoc tasks and executing them across hundreds of Puppet nodes. The latest release of Puppet Enterprise includes tools for inspecting packages deployed on and a tool to simplify configurations of those nodes.

    Puppet has also expanded its alliance with Splunk to tighten integration between the two IT operations’ platforms, and formed new alliances with Baracuda Networks, CloudPassage, Conjur/CyberArk, Cumulus Networks, Electric Cloud, F5, Intelliment Security, Onyx Point, Praecipio Consulting and Sensu. In addition, the Puppet module for the Microsoft Azure cloud has been updated to provide access to more disk storage, expanded networking support and support for Azure tags.

    Tim Zonca, vice president of marketing and business development, says with these products Puppet should no longer be considered a one-product company. It is now committed to developing a full range of DevOps management capabilities. That’s significant, notes Zonca, because today there is too much tension between IT operations teams and developers caused by silos of automation across various DevOps processes. As part of that effort, the company is also committing to start to synchronize the release cycles of the various elements of its portfolio.

    As DevOps continues to mature, the line between how infrastructure, applications and security are managed continues to blur. Many IT organizations prefer to acquire a set of DevOps tools from one vendor because it simplifies purchasing and support. Over time, those vendors combine those tools into an integrated suite that aims to unify the management of infrastructures, applications and security. Most vendors today are a long way from unifying those functions, but a wave of consolidation across the DevOps sector suggests the race is on to provide a unified DevOp stack capable of being employed across multiple platforms.

    The percentage of IT organizations that make extensive use of IT automation frameworks such as Puppet is relatively small. Much of the resistance to IT automation frameworks can be attributed now to simple inertia. But as the size and scope of IT environments exceed the capabilities of an internal IT team to manage manually, it’s now only a matter of time before reliance on IT automation increases.

    Puppet and other vendors also have infused their platforms with machine learning algorithms to expand the scope of what can be automated within an IT environment. In general, Zonca says reliance on those capabilities tends to increase in time once the DevOps teams gains confidence in the algorithms’ abilities to make the right decision. Until such time, Zonca says most IT professionals employ those algorithms to either present them with a series of suggested options based on the most recent events that have occurred. Given the nearly infinite number of possibilities that can be inferred from those events, most DevOps teams already are going to need all the machine learning algorithm help they can get.

    — Mike Vizard