devopsy.kinsta.cloud

Tag: devops transition

  • Successfully Integrating DevOps while Deploying Cloud Applications

    Successfully Integrating DevOps while Deploying Cloud Applications

    Transforming to a high-performance DevOps environment can provide competitive advantages, but it requires change—and that doesn’t come easily to most organizations. DevOps requires cultural changes that are inherent to automating previously manual tasks: They are perhaps intimidating to those involved and they require flexibility and enterprisewide buy-in to get right. Furthering these people-side transformational complications are cloud application deployments, creating a need for enterprises to deliver innovative technologies and services with greater speed and quality—without hits to reliability and security.

    DevOps Blended with AWS Proficiency

    One approach to this problem is blending DevOps knowledge and Amazon Web Services (AWS) proficiency to guide development teams to better align the people, processes and technology needed to facilitate successful cloud initiatives.

    In transitioning to a more modern, DevOps-driven approach, companies often encounter a number of challenges, on both a technological and cultural level. The most successfully integrated DevOps occurs as a function of value analysis and process overview, addressing the individual needs of an enterprise rather than fitting them into a preset mold.

    Implemented correctly, DevOps blended with AWS proficiency allows organizations to maintain quality and configuration of their infrastructure environments, allowing application development teams to retain control over their processes and toolsets. AWS also allows the enterprise to maintain security: Rather than protocols that are standalone, they’re built into IT processes from the beginning, allowing customization with ease.

    AWS understands what is important to its partners when building tools, successfully addressing needs while staying ahead of the demand and, in turn, saving time. They accelerate the ability to deliver and allow an enterprise to focus on what’s most important during their journey to the cloud: value analysis.

    Fundamentally Designed to Refine Business Processes

    It is very important to approach projects first from a top-level view: Where does this piece of work fit into my broader organization?

    DevOps at its core is fundamentally about incorporating different disciplines of a business to create better practices than what are already in place. When an enterprise chooses to implement automation, it typically gains a better view of its business as a whole, incrementally increasing awareness at a birds-eye level. When complex business functions and operations are laid out in more mathematical terms and formulas, it suddenly becomes clear where applying automation can reduce waste.

    Getting these changes implemented quickly and with as little effort as possible naturally leads to successful automation. Enterprises remove such tasks that traditionally required an excess in resources by asking, “What value doe this process add? Is there a more efficient alternative?” With automation, these useless business practices are eliminated, freeing resources for more important initiatives.

    Increase Employee Awareness, Increase Productivity   

    One of the most important parts of the entire DevOps integration process is ensuring that everyone understands each other and their role. Properly embraced, a DevOps culture will be characterized by increased collaboration, shared responsibility and autonomous teams—leading to improved quality, valued feedback and the end goal of increased automation.

    People are naturally resistant to change. Members need to be aware of the business and how they—and will continue to—fit in.

    Ultimately, DevOps is not something that can simply be bought. Success during implementation requires the application of technologies, tools and products that are actually a fit between new processes and existing systems.

    — Ashley Stovall

  • Transition to DevOps Increasing Across IT Firms

    Transition to DevOps Increasing Across IT Firms

    Demand for faster product development and quick market release created a need for increased collaboration between Development (Dev) and Operations (Ops) teams, which eventually led to “DevOps.” With this, transition to DevOps has become one of the key points of discussion across many IT firms. This article gives you an overview of the demand and trend for organizations to transition to DevOps.

    Rise in IT innovation and burgeoning digital revolution have led to the demand for faster development and quicker releases to stand out in the IT competitive scenario. This transition eventually led to a new culture that saw collaboration between two key IT teams, development and operations teams, which the industry calls DevOps.

    DevOps established a new style of IT functioning, easing different phases of software process from product development to testing and final market release, all in a rapid and reliable way.

    Why DevOps Transition?

    Rapid delivery of independent software components and continuous integration of the same with production systems forms the key principle behind DevOps functioning.

    DevOps is often confused with Agile methodology. Though they share similarities in providing improved IT performance through rapid development, DevOps stands apart from Agile because of its efficacy in the software deployment phase, ensuring a constant communication between the two teams. Thus, DevOps is often termed as a successor to Agile.

    A collaborative approach, key for information exchange across the line, is one of the major factors driving firms to undergo DevOps implementation.

    Though DevOps is well-known as a merger of development and operations teams, an effective DevOps model extends beyond that to other key functional areas of organizations.

    Breaking the old trend of limiting individual teams to their respective work domains, DevOps brought in a scope for knowledge-sharing among them, wherein developers can extend themselves to testing and deployment and operations team members can upgrade their skill set, learning new languages, architectures and tools.

    Increased Demand for DevOps Resource

    Transition to DevOps holds a key demand in the fast-growing IT market, wherein managing with the existing infrastructure or resource plays an almost equal role as coming up with something new.

    Greenfield projects aside, DevOps deployment is most often seen in brownfield projects that encourage building on the existing resources.

    With this situation in place, there is also a lot of demand for DevOps resources across firms. The “2017 Open Source Jobs Report” from the Linux Foundation shows 60 percent demand for DevOps human resources among more than 2,000 IT open source professionals and IT hiring managers.

    This clearly shows the level of demand that transition to DevOps is holding in the IT industry.

    “If there isn’t an existing DevOps role within your company, software developers should spend time sitting with the operations team or vice versa to understand how their processes work and how they can be improved through collaboration,” said Mike Durney, CEO of the job-hunting site Dice.

    The report found:

    • Nearly 50 percent of hiring managers are keen about those DevOps resources with professional credentials such as relevant certifications
    • More than 47 percent of the companies are ready to fund certification programs for their existing personnel
    • 42 percent of companies are keen on adding DevOps skills to their hiring portfolio
    • “DevOps Engineer” profile ranks second in Glassdoor’s Best 50 jobs in America

    Despite its advantages, however, DevOps has a few challenges to overcome related to application integration, test automation, budget and skill set, among others.

    — Veritis

  • There is No ‘I’ in Team: Transitioning Engineering Teams into a DevOps Model

    There is No ‘I’ in Team: Transitioning Engineering Teams into a DevOps Model

    As the pace of development and business continues to scale, teams need an agile and collaborative work environment to succeed. Moving to a DevOps model is a critical part of setting your engineering teams up to succeed, but making the transition can be challenging for many companies.

    What’s the deal? – Why you need a DevOps model

    DevOps is a movement in the software world  that focuses on collaboration between developers and operations, customer empathy and infrastructure automation. In traditional models, developers write code and then hand it to operations teams to deploy and and run in a production environment. This often leads to a lack of ownership between the two teams (“It worked on my local box!”) as well as a slower pace of development. In a DevOps model, by contrast, the two teams work closely with each other, and toward common, customer-facing goals – developers take ownership of their code even while it’s in production, and operations teams build tooling and processes that help developers write, test and ship code faster and more easily.

    By breaking through traditional developer-operations walls, development happens faster and with more customer empathy, ultimately resulting in a better customer experience and a happier team. Rather than seeing the other team as a gate or obstacle, if done right, developers and operations see each other as teammates working to deliver value to the customer and business.

    Unfortunately, introducing DevOps culture and practices to your company isn’t easy. Big changes to long-entrenched silos can generate resistance, and business leaders are often scared of the costs that come with change. To combat these concerns and hesitations, we’ve highlighted a few tips for transitioning to a DevOps model.

    Start with Collaboration – what’s working and what’s not?

    At the heart of DevOps is improved collaboration between your Operations and Development teams. You’re probably not starting from a vacuum, though – look at and talk about the best examples of how your operations and software development teams are collaborating today. Are there particular dev/ops groups that are already working tightly together, championing great communication or doing joint planning? Focusing on what is already working and how to make it work better, rather than what’s broken, keeps things positive and more likely to succeed.

    You could set up a group brainstorming session to discuss, or have one-on-one conversations with individual team members, depending on the format that you think will help people open up more easily. This article highlights opportunities for collaboration across the application delivery lifecycle, and could provide a useful framework for asking questions and identifying opportunities.

    In addition to the state of collaboration, you’ll also want to look for process successes and breakdowns in how you deploy and maintain applications, services and infrastructure. Identify the biggest opportunities for improvement – do your builds and test take hours? Are your 20 development teams all competing for the same three staging environments? Being able to quantify the impact of these pain points can help defend the transition to business stakeholders who may not have as much on-the-ground context about your teams’ pain points.

    It’s also important to build an understanding of the different perspectives operations and development teams may have. If your organization has traditionally been very siloed, thinking about other teams’ goals when planning and prioritizing may be a new mindset. Sharing each team’s objectives and what success looks like for them can help build this understanding and empathy. Focus on transparency (a framework like OKRs can help) to avoid conflict from mismatched assumptions about priorities.

    Create a plan  

    Once you’ve identified opportunities to improve the collaboration and workflow between developers and operations, it’s time to create a specific plan. Pick key opportunities and identify the first few steps to make a difference. Courtney Nash recommends starting with a group of people who are receptive to the vision and picking a small product or service as a test-bed. When implementing big changes, it helps to start small and scale from there after proving success.

    Engineers are not always known for their people skills, but transitioning to DevOps is as much about people as it is about process and tools. Throughout this whole process, you’ll want to be investing key stakeholders in your team and company in the transition. Change management sounds awfully corporate, but at it’s heart, it’s about making sure you build support for your projects and goals by collecting input from key stakeholders: gathering their feedback and goals, sharing and re-shaping your plan based on their input, and communicating your progress with them. It’s always easier to work in silos with people that already agree with you, but for lasting change, you’ll need to invest in building support across teams and throughout your organization.

    Finally, pick realistic timelines and objectives. It’s important to note that some effects of the change may take longer to realize as people ramp up on new tools and ways of working. Don’t discount or neglect the amount of time required for training, and try not to be fazed if the first project you pick doesn’t turn out to be a good one. As Courtney Nash mentions, Nordstrom.com realized their first project was not ultimately the right one to start with. Importantly, they didn’t give up, instead choosing a different, better-suited application.

    Measure and reflect

    While it’s rare for timelines in complex systems to happen exactly as planned, it’s important to timebox your work so that you can measure and reflect on how it went.

    After the specific milestone you’ve chosen, bring stakeholders together and run a retrospective. There are a lot of great resources out there to help with good retrospectives, but regardless of approach, make sure you make an intentional space to look critically at your results, celebrate success, and think about how you’d like to change or iterate the process for the future.

    When reflecting on progress, it’s important to be candid and honest while assuming the best intentions of your teammates. You are guaranteed to make mistakes – that’s inevitable with any new process – but remember (and help others remember) that you’re all working toward the same purpose and share a common set of values and goals.

    Don’t give up

    Adopting DevOps is a big change for an organization, and there will be bumps along the road. At the end of the day, though, the rewards of tighter collaboration among teams and a more empathy-driven engineering culture can be really powerful, and will show in product quality, velocity and team morale.

  • Separation Anxiety & the Leap from Dated IT Approaches to DevOps

    Separation Anxiety & the Leap from Dated IT Approaches to DevOps

    Never ASSUME!

    I assumed that the drag on moving from IT as we knew it to a DevOps approach (with its continuous software deployment and other advantages) was due to the separation anxiety and fears of loss or change on the part of enterprises on the whole. As you may know from the 70’s TV show, The Odd Couple and its character Felix Unger, played by Tony Randall, you should “Never ASSUME, because when you ASSUME, you make an ASS of U and ME.” *

    And so I was mistaken, but not far off from the truth. “I don’t think that enterprises as a whole fear change so much; what I think happens is that individuals fear change and erect a number of barriers to change,” says Alan Baker, President and Chief Consultant, Spitfire Innovations (link), a business process optimization consultancy. Let’s investigate some of those fear-based barriers.

    Barriers to DevOps, Based in Fear

    The first barrier is resistance due to a loss of knowledge. “There are individuals within IT who have built their careers around the current practices and approaches,” says Baker. These IT professionals have developed reputations as subject matter experts, which they truly are. This enhances their value, but only so long as the current subject matter retains its value. By moving to DevOps and making material changes to the way developers and IT operations accomplish their work, the enterprise will diminish their knowledge as well as perhaps their status and their usefulness to the company. They have a vested interest in the status quo. They would have to have more to gain by joining DevOps than by opposing it in order to move to a more progressive approach to change management, according to Baker.

    The second barrier is political; it’s the loss of control. IT professionals who shoulder accountability for operations day in and day out are typically averse to loosening their grip on how change is introduced into their environment. “That’s understandable, because once something is productionized it’s their responsibility; they want to be completely sure that the deliverables are defect-free,” says Baker. For this reason, these individuals are going to need assurances that the new processes will maintain the integrity of the deliverables, says Baker.

    The third barrier is structural. In an environment where some form of management by objectives is practiced there is typically little alignment of objectives between different groups. “Day-to-day operations typically have objectives relating to efficiency (such as throughput), whereas development objectives are driven by dates and cost,” says Baker.

    Reaching for Change

    If the enterprise is going to break down these barriers and change its practices, all the stakeholders need to come together and agree on a plan of action. The stakeholders, including anyone tempted to resist DevOps, need to fully and collectively develop the future state of the enterprise, focusing on shared objectives. “All groups that are concerned need to have a set of common goals to work towards that satisfy all stakeholders,” says Baker.

    There also need to be necessary supports. A DevOps approach requires increased integration and communication between all of the stakeholders. The walls need to come down. “This openness doesn’t necessarily come naturally to all IT staff; the organization will need to invest in the appropriate education and expert guidance (as well as some patience) to ensure that the cultural change has a chance to take root,” says Baker.

    The final item consists of two value propositions. These value propositions give the organization the opportunity to demonstrate its vision, transparency, and resolve. The first concerns the need of the organization for someone to take an approach that answers the who, what, when, where, why, and how questions surrounding DevOps activities and responsibilities, and then to clearly articulate all aspects of the change to everyone. It’s a necessary step in order to get the buy-in. The second value proposition is directed at the individuals impacted by the change. Help answer the question ‘What’s in it for me?’, particularly for those individuals working themselves out of a role.

    *It was one of the show’s funniest and most memorable lines and is repeated to this day. Though proper attribution for the original comment may ultimately be out of reach, see http://en.wikipedia.org/wiki/Jerry_Belson for the Television Writer who placed it in the Odd Couple episode.