staging-devopsy.kinsta.cloud

Tag: pilot

  • Dear Management: Letter to DevOps Leaders

    Dear Management: Letter to DevOps Leaders

    My occasional reminder that “Change is good, but predictability is better,” is in the form of a message to DevOps upper management. I thought it would be fun to write, and would offer a different perspective and drive than normal. Hope you enjoy!

    Dear Management,

    Too much of anything is bad. No matter the topic, once too much of it is present, problems crop up. That is just as true in DevOps as any other topic.

    We need some level of standardization, because too many different toolchains is bad. If there is a tool learning curve before team A can assist team B, we are not taking advantage of standardization. In fact, we’re creating a well of technical debt that someone is going to have to clean out. Are we really going to maintain separate toolchains for each project on top of the variety of languages and targets we already have to manage? For years? Is that the most productive use of our time? Do we even have an exit plan to replace that dying open source project that is the core of one of our apps?

    So let’s do some level of standardization on toolchains, shall we? That is the most stable route to standardized tests and easy-to-troubleshoot environments.

    But let’s not get too standardized, either. Because too much of anything is bad, and too much standardization is stagnation.

    We have never seen an environment nor talked to peers and heard them say, “Oh yeaaahh, our environment is perfect! We made everything work smoothly, and all metrics are headed in the right direction while development and deployment have gotten easier.” Those people don’t exist, because in our age of near-constant change, those environments don’t exist.

    In spite of standardization, we need to keep trying new tools, options, environments and policies to increase our quality and deliverability. Give a team the OK to ignore standard X and bring in something they think is better suited to their needs; then see if you can adopt it more widely.

    In short, we want standardization to make our jobs easier, but we don’t want stagnation. We don’t need fifty languages, twenty CI tools, and half a dozen security scanners. We need a few good ones, and the ability to look around at new products/ideas in the space to find better ones.

    In fact, that app that no one is allowed to mess with? Let’s rewrite it, so it is newer and more maintainable; and, while we’re at it, let’s try some of these new and different products and processes. After all, we’re biting the bullet re-writing, we may as well take the extra step, and we might find something useful to the broader collection of DevOps teams.

    And trust us when we tell you a tool or process is the right fit. Ninety percent of the time, the buzzword of the day that you saw on Twitter is either not ready for production yet, or is already in use at our org. It’s our job, so we’re paying attention. And buzzwords are marketing lingo aimed at you, to force us into using something we’ve already looked at.

    You’re doing a good job, we just think we could be doing better. Give us standards, along with room to challenge them a bit. Of course some of us won’t be happy when our tool isn’t the one chosen to standardize on, but we’ll pull together in the end, if you remind us that we’re working to put the org on a more stable and maintainable footing.

    Thank you,

    More of your DevOps employees than you think.

  • Pilot Testing DevOps in a Pandemic

    Pilot Testing DevOps in a Pandemic

    Savvy organizations are using the pandemic to drive innovation by pilot testing DevOps. As health experts brace for an exponential rise in COVID-19 cases across the nation and vaccine distribution ramps up, many states and cities are still implementing significant measures to reduce the virus’s spread. As shutdowns impact cities coast to coast, organizations are updating their business continuity processes and disaster recovery plans for COVID’s next wave.

    Software developers and testers are typically perceived as being able to adapt quickly to changes and the fast pace of IT. Since the beginning of the pandemic, SaaS adoption has become a go-to platform for businesses of all sizes looking to ensure business continuity and enable innovation during these uncertain times.

    To meet this demand, developers have worked at ever-increasing speed to configure, test and deploy advanced features and services to their clientele. This quickened pace, for some, has led to the abandonment of proper security guardrails.

    There are a few key ways to mitigate the pressure and risks involved in this accelerated environment, balancing continual innovation with ensuring developers and testers are applying robust security strategies.

    Fail Fast, Succeed Early

    At its core, DevOps is the process of using development technology to solve operational IT problems. Having a well-defined strategy helps; however, it’s nothing without proper implementation and calculated risks. Both of these factors help your organization achieve its goals in a shorter amount of time.

    Here’s an example. One of my colleagues worked on a software development project where, instead of testing one process at a time, they tested 30 different scenarios simultaneously to see which would be the better strategic fit for their organization. They could have planned and tested, one scenario at a time, for six months; however, in three weeks, they could determine their next step in a much shorter amount of time. Methods like this begin with a strong innovation culture where everyone aligns on the same goals.

    Additionally, access to funding also becomes essential, along with the ability to hyperscale. Cost does become a factor; however, this simultaneous testing and fail-fast methodology saves teams an extraordinary amount of time. The goal of failing fast in DevOps is not to increase the chances of failure, but to encourage experimentation, making it a surefire way to bring products to market quicker.

    Put the Cultural Shift into High Gear

    Whether or not a company finds itself in crisis due to the pandemic, leaders need to remember that tools are not the magic bullet of DevOps; culture is. DevOps is not only a philosophy, it’s a mindset that promotes collaboration, culture alignment and lends itself to innovation. Innovation is often a term that scares companies or teams, who may feel it is out of their reach. However, consider this: the very act of innovation involves trying. If you’re not putting yourself in the race, how can you win?

    From ideation to pilot testing, organizations need to understand that they can try something without being “all in.” Innovation is everywhere and within every process. What keeps the culture of innovation alive and well is building an ethos of collaboration; that leads to a team that not only thinks but believes that innovation can happen. Culture becomes everything when your organization starts to look for new and innovative ways to push your business and your clients further, successfully.

    There is an important caveat, though. Often, leaders introduce policies and procedures to their team without providing a long-term vision of the outcome(s). This often leads to long-term adverse effects, simply because the underlying organizational culture is not healthy. Even during a global pandemic, where budgets may be tighter, teams are leaner but innovation is still the goal, there must be vision, transparency and effective communication to allow for proper implementation and execution. All of these components start with culture.

    Scale DevOps Through Automation

    Working on a test automation strategy is the best way to set your organization up for success. Along with culture and collaboration, automation is a key pillar of DevOps. Research shows 60% of occupations have at least 30% of constituent work activities that will be automated by 2030, globally. Historically, teams have been skeptical about automating their work, and push forward with an “I can do it myself” way of thinking and working. COVID-19 created a massive uptick in demand for IT services, and teams’ pressure to perform has also increased.

    For DevOps teams to successfully “scale up” right now, the implementation of continuous automation into the testing process is critical. As with any type of new technology implementation, there are warning signs to consider.

    As wonderful as automation can be, the process often creates a skills gap; however, this does not mean leaders should shy away from the automation process. However, leaders must be aware of this and come up with a strategy to ensure training opportunities are available to close these gaps.

    The pandemic has reinforced how swiftly change happens, and that companies must be flexible and respond quickly just the same. While IT systems are built to extend and adapt, accelerating delivery cannot happen at the expense of business continuity. Pilot testing amid a global pandemic encourages a culture of transparency, collaboration and experimentation that will empower teams to track inefficiencies at an increased rate.

  • DevOps Abandonment: Reasons Not to Give Up

    DevOps Abandonment: Reasons Not to Give Up

    The Never-Ending Story

    When a new process or methodology comes along—particularly when one gets a lot of attention like DevOps has—there always will be failures. I’m not talking about those always-present group of people who say they’ve seen this cycle before and, thus, it is just a fad; I’m talking about actual implementers who, in the end, come up empty-handed.

    DevOps is no exception. In fact, because it radically changes much about IT, it probably has a higher rate of this problem than most new methodologies.

    The end result is easy enough to identify: Either an organization abandons DevOps altogether or shunts it off into that area where other processes and technologies have been implemented by only one team and eventually die.

    Problem Children

    In almost every case of DevOps failure, people are the problem. That is not to say people purposely undermine the system, but IT is built, managed and run by people. And the breadth of people in an organization has immense influence on the success or failure of DevOps (or any other IT initiative).

    With that said, let’s look at some problems that contribute to DevOps abandonment organizations should avoid in their attempts to evaluate/implement DevOps.

    Team Isolation

    It is a standard enterprise reaction to split off a team to look at a new technology/process and isolate them from the rest of IT. I was the first hire in a “New IT” at an organization—it was weird to have rooms of cubicles filled with people I was not allowed to talk to. One of several keys to success in DevOps is communication, and no application or application portfolio works in a vacuum. The need to discuss server space, security, routing and a host of other topics with core IT means isolation will not work. It is one thing to clear the pilot team’s workload to allow them to focus on assessing DevOps for the organization, but it is quite another to isolate them (functionally, geographically, whatever). If they find some quick-hit streamlining opportunities in standard operations, don’t you want those shared with the wider IT department?

    Getting the Tools Side Right, but Missing the Culture Side

    I make no secret about the fact that I’m a bigger fan of the automation side of DevOps than the culture side. But sooner or later, all the whiz-bang tools are deployed, and culture becomes the main focus. That includes not only communications between different parts of the DevOps team, but also the “can jump in and do” mentality that is more prevalent in DevOps than in a more divided IT environment. Getting the culture and communications down early is important for success. And success is important for wider gains in IT’s ability to meet the demands of the business.

    Adding to the Workload of Overloaded Team Members

    This is perhaps the most common pitfall that causes organizations to leave DevOps or minimize their exposure to DevOps practices. DevOps holds the promise of increased productivity and decreased backlog. But it is a promise. Implementing tools and forging new relationships and new paths of communication … these things take time. And that time is added to existing workloads, unless steps are taken to lighten existing workloads.

    The team working 10 to 12 hours a day just keeping the lights on will not side-track into anything that requires a definite investment of more man-hours unless it is mandated to them by the business. Asking them to start working on it is a recipe for failure; the best you can hope for is some automation that makes their life easier in some other way.

    Not Managing/Meeting the Expectations of Various Leaders

    What line of business (LoB) leaders and the CIO expect out of DevOps are different things. While vaguely similar—increased responsiveness to business needs is normally 100 percent shared—the details show different concerns.

    It is up to the CIO to manage what those under him in IT expect/demand from DevOps, and what those peers in the line of business expect from it. There is no reduction in commitment from LoB teams—indeed, one could argue there is an increase, as IT is no longer the bottleneck. And, perhaps most importantly for some organizations, DevOps doesn’t make IT mind readers any more than previous new methodologies did. The LoB still must define what is needed and get requirements into IT.

    Trying or Retrying DevOps? A Few Tips

    Pilot

    Run a pilot project. Lighten the load of the project team so members can focus on DevOps and bring its value into the team. Do not isolate them in any way. Including other teams by asking for help/ideas should be encouraged. In fact, if the pilot team is motivated and enjoying the pilot, this type of interaction can help smooth the way for extension of DevOps to the wider organization.

    Use Existing Resources/Management

    Don’t bring in specialists to do DevOps. DevOps can be learned, and there are a ton of resources available, so use people who know your environment and can apply standardized tools and practices to it. That includes management. The last thing an organization should have in a pilot is a manager that knows DevOps but not the relationships within and special quirks of your organization—both technical and social.

    Pick Your Pilot Carefully

    Pilot a project that is relatively small but is visible to the organization. Actively manage expectations, and see where DevOps takes you.

    Rethink Everything

    Empower the team to look critically at every single process/workflow and see where the most gain can be had. DevOps is not a switch; prioritizing high-value/important items for change in this iteration and lower-value items for future iterations is part of the process. But if you don’t look at everything, you can’t guarantee you’re getting the most bang for your buck on this—or any—iteration.

    Clearly Communicate Goals/Changes

    Make sure everyone in IT and out understands what the pilot is testing. Is it increased time to market? Is it ability to apply tools and processes to intractable sub-projects? Is it a test of the benefits touted by talking heads? Communicate what you are measuring and how you’re measuring it. If possible, share a dashboard showing those measurements with everyone who cares to follow along.

    This Time is Different

    DevOps is different from any other new methodology that has gained traction for the operations side. Ever. I’d say it was different than any other new methodology at all, but Agile is the precursor to DevOps on the Dev side, and they share a lot. It challenges decades-old thoughts on the best way to do things. It will fail sometimes, for a variety of reasons. Give it the best chance for success that you can, don’t tie the pilot team’s hands and use it where it succeeds, even if it doesn’t include every project in the portfolio.

    In the end, if it really does help the business succeed, then—like it or not—it is the right tool for the job.

    — Don Macvittie

  • Is DevOps Transformation a Holy Grail?

    Is DevOps Transformation a Holy Grail?

    Both development and operations teams are popping up in enterprises all over the world, and even though DevOps programs are still in the early stages, our ultra digital world calls for even more software applications. This is why many analyst and consultants alike believe that, in the near future, DevOps will be even more powerful than legacy IT. DevOps will be something businesses of all sizes will not be able to live without and the sooner you initiate the DevOps transformation, the better.

    Why DevOps Transformation?

    One of the most exciting aspects of DevOps is enacting technology practices and architecture that help organizations create an agile and continuous product flow, from development to testing, operations and all the way to deployment while increasing stability, reliability and security at the same time.

    More importantly, adopting DevOps can enact changes in the culture of your business, such as allowing teams to work more quickly with more independence. Back in the days before DevOps, deploying even a minor update, upgrade or bug fix would involve literally hundreds of developers doing weeks worth of work.

    Today’s top-performing businesses and DevOps adopters are deploying much faster, and the products they release generally have greater reliability. Still not convinced that DevOps is the holy grail? Consider the following.

    Focus on Speed, Not Cost

    Do you want to achieve the same capabilities of Amazon and Netflix? Of course! Who doesn’t? It’s easy to make an excuse that they have a lot of money to spend, but, when we look deeper, companies that achieve DevOps success are more focused on optimizing speed, not cost. Organizing and optimizing for cost creates functional silos for networking and database people, server admins and many others.

    When you optimize for speed, you are willing to cultivate talent from within, increase engineers’ salary and send them to conferences. You would not necessarily do these things if you were simply optimizing for cost. There are a whole bunch of techniques we can use to optimize for speed, such as using small, cross-functional teams that can deploy value to the customer independently without having to rely on hundreds or, in some cases, thousands of people.

    Best of all, you don’t have to be a big conglomerate to make this transition. Even small and medium-sized businesses can choose to optimize for speed, break down silos and get their product to market faster. After all, this is what DevOps is all about.

    Software Speed vs. Quality

    Businesses that rely on developing and deploying software to support or supply their customers often are faced with choosing speed or quality. If you go to market before your competitor(s), you could be cutting corners in terms of testing and quality assurance, which can ruin your launch. However, if you wait until your code is perfect, you could end up lagging behind in the race for the next big breakthrough. Fortunately, the DevOps approach can resolve this dilemma while improving the bottom line.

    Way back in 2015, the “State of DevOps Report” collected the DevOps health and habits of more than 20,000 tech professionals and found that top performers using DevOps show more agility and reliability in their releases and they were twice more likely than non-DevOps users to exceed productivity goals. In the roughly 800 companies that had a stock ticker symbol, the top performers had an almost 50 percent higher market capitalization growth over three years. This indicates that DevOps is great for IT performance as well as organizational performance.

    What everything boils down to is that all modern businesses are increasingly more reliant on technology when it comes to acquiring new customers and bringing value to those customers. It is becoming increasingly apparent that agility and speed are key attributes for companies who want to win in today’s marketplace.

    DevOps Transformation Guide

    With all of the benefits listed above, you are probably eager to get started with DevOps. Here is a simple step-by-step guide to assist you in your DevOps transformation.

    1. Conduct an Enterprise Readiness Audit – The highest probability of a successful DevOps transformation is when it is championed from the very top. The participation of business leaders is just as vital as operations, security and development teams. To get everyone on the same page and to ensure that your DevOps transformation gets off to a good start, seek assistance from an experienced, external consultant or coach. The purpose of this first step is to get executives to buy in, create mutual goals and get an understanding of what an Agile-DevOps program looks like.
    2. Create a DevOps Center of Excellence (CoE) – One of the most important things you must do here is designate an Executive DevOps lead with enterprise authority. There is no use in creating this Center of Excellence at the incorrect organizational level. It must be spearheaded by someone who has the support and trust from all branches of the organization including delivery and vendors.
    3. Create a Program Governance – Such a program will include creating a communications plan, an enablement program as well as establishing program KPIs. In terms of making a cultural impact on your organization, this is perhaps the most important step. The roles and responsibilities of practitioners will change with Agile and DevOps and it is vital that they understand collaborations between structures where historically animosity could have existed so they can break down these organizational silos. The KPIs will also need to be transitioned from individual metrics to holistic customer business results.
    4. Create a Project Intake Process – Project intake really sets the tone for how successful each new sprint that comes into the program will be. What matters here is not the tools and process, but rather the proper sizing of the tools and process. There is a need to fit for purpose when selecting accelerators, toolchain and development methods. Once it is created, the communication of the intake process needs to be disseminated across the organization. Keep gathering feedback and and continuously evolve and mature based on this feedback.
    5. Identify and Initiate Pilots – To achieve the highest probability of success, apply this step to a specific portfolio of applications or a domain solution. The purpose here is to create a value-stream map of a specific application with company wide participation on all levels. This needs to be done with the necessary amount of detail to identify manual and automated processes, end-to-end process tooling and the people and skills that are involved.
      The next aspect of the intake project is the collaboration between the subject matter experts from the Center of Excellence with the project team. The goal is to advise on “to-be” processes with proper tooling, reusable assets and automation. As the application goes through the development and test cycle, be sure to identify and capture the KPIs for the program in order to compare with existing KPIs.
    6. Scale Your DevOps Program – This final step involves taking feedback from the pilot metrics and scaling them by taking different application portfolios and running multiple release trains. It is not enough to merely do automated deployments and daily builds. The last, but by no means least, piece of the DevOps puzzle is constant feedback and optimization.

    Key Takeaways

    • To keep up with top-performing businesses and stay alive in today’s ultra-competitive, fast-paced environment, implementing DevOps is an absolute must. DevOps is not solely reserved for giant enterprises such as Amazon and Netflix and can be implemented in any-size organizations.
    • In the not too distant future, DevOps will become something businesses of all sizes will not be able to live without. To reap all the benefits DevOps has to offer, the sooner you make the transition to DevOps, the better.
    • With DevOps, there is no longer a reason to choose between speed and quality when deploying your software. When implemented properly, DevOps will allow you to deploy software with both agility and reliability increasing your customer base and the bottom line.
    • The step-by-step approach mentioned above can and should be implemented in any flavor and variety that best suits each individual organization’s needs and constraints.  Pay particularly close attention to large gaps or excessive deviations as they are red flags which will need to be corrected.

    About the Author / Stanislav Ivaschenko

    Stanislav Ivaschenko is a certified AWS solutions architect at Squadex with more than 10 years of professional experience in building, delivering, supporting and optimizing a broad range of software applications. From bare metal to the cloud, from monolith architecture to microservices his expertise and experience help to meet business needs for startups, mid-sized companies and large enterprises. He has experienced a large number of DevOps and infrastructure related tools, services and management practices.