devopsy.kinsta.cloud

Tag: rapid development

  • Understand Why You’re Doing DevOps

    Understand Why You’re Doing DevOps

    DevOps has been all the rage for a few years now. It has quickly matured from a fringe concept to a mainstream imperative, and organizations that haven’t already embraced DevOps are scrambling to understand and implement it to keep up with rivals and remain competitive. Despite its benefits, though, DevOps may not be for everyone. Before diving into the DevOps deep end, you first should consider what your objectives are.

    To frame the issue more precisely, it’s not that organizations necessarily should avoid DevOps altogether. It’s just important to go into it with your eyes wide open and to understand why some DevOps projects fail. According to Andrew Storms, VP of Security Services at New Context, it’s always for one of four reasons: cultural roadblocks, failure to identify and take action on mistakes as you go, failure to learn from past mistakes and most importantly, failure to include security—either early on or at all.

    Let’s break down those four hurdles.

    Face Cultural Roadblocks

    DevOps is different things to different organizations, or even to different teams within an organization. There are many definitions of what DevOps is or is not. There is a fairly unanimous consensus, though, that DevOps is first and foremost a function of culture.

    Cultural roadblocks, Storms said, are by far the most common reason he sees DevOps fail. “It’s rarely a technical tools problem; usually there’s a disconnect between the DevOps team and executives or other parts of the organization. A concerted effort must be made to get everyone in the organization on the same page. Everyone is fighting for the same thing, but too often, they don’t realize it.”

    Fix Mistakes

    One of the outcomes of the DevOps culture shift is a fundamental change in corporate bureaucracy and the rigid processes that segregate teams and impede progress. DevOps enables organizations to work more seamlessly and produce results more quickly. It also allows issues and mistakes to be identified and resolved on the fly. “Smaller incremental changes are always easier to handle than a large monster of a release, which can include hundreds of changes,” explained Storms. “For example, teams should look for the single change in a monthly release that resulted in an unexpected security hole, instead of thinking they’ll tackle all changes with a huge release down the road.”

    Learn from the Past

    One of the most important things for business in general to help them understand is learning from past mistakes. With DevOps, it’s crucial. Organizations often only conduct investigations and postmortem analyses in the event of an issue or catastrophic failure. In that situation, the teams and individuals involved are immediately on the defensive and likely to go into “CYA” mode.

    To effectively understand and learn from the past the discussion has to be neutral and without blame or consequence. It’s a difficult concept for organizations to grasp. The key to blameless meetings is to conduct them as a regular occurrence rather than a response to a negative situation, and to foster a culture where failure is acceptable as long as it is used as a learning experience.

    Storms also suggests changing the name to “After Action Reports” to remove the negative stigma. “Postmortem implies a dead body. After Actions Reports are imperative after any event regardless of the type of outcome.”

    Start with Security

    Security is an Achilles heel of development in general, but the rapid pace of development in a DevOps environment makes it even more critical that security be integrated from the beginning. Failing to consider security is a disaster waiting to happen.

    Those responsible for security often don’t even know about a project until after it’s already in production. Storms cautions organizations, “Untested and unreviewed code or designs in production represent both a large security risk, but also a risk to the business and your customers. Security needs to be part of the SDLC (software development life cycle) and DevOps from day one.”

    DevOps is not a silver bullet. Nothing is. There are a variety of unique advantages and benefits that come from successfully embracing DevOps, but to realize them you need to start with a clear understanding of your own objectives, and how DevOps can be leveraged to help you achieve them.

  • Build fast, then build right 

    Build fast, then build right 

    This article is a part of a series of pieces on digital innovation, accelerating change and the rise of the coded business from innovators in the Chef community. This article is by Kate Matsudaira, founder of Popforms

    Businesses have always needed speed and scale to meet customer demands. Today though, the kind of speed and scale businesses require to stay ahead of voracious consumer appetites and competitive offerings can only be achieved through a combination of: automation; internal culture shifts internally to integrate developers and IT functions closer together and more closely with the business; the use of commodity hardware; and a willingness to offer and embrace imperfect products. Then, and only then, will companies realize the benefits of moving quickly to deliver product, and also in unlocking innovation in this process to generate new revenue streams.
    For this to work, CIOs and CTOs must fully understand the business. They can no longer just be experts in technology. That’s not enough. For IT to evolve from a cost center to a revenue generator, IT must be integrated and engaged in the enterprise – large and small enterprises alike.

    Take a specialized candy company, for example. Before, it would not have been economical for this kind of business to scale at speed. But now, with minimal expense, it can acquire the compute cycles it needs, automatically deliver working code into its expanded production environment, and keep IT costs down through automation.

    Also, with the cloud and SaaS, costs for technology are way down – or, in some cases even free. This commoditization of technology is hugely positive for IT and its new role in many companies. Technology is no longer such a massive sunk cost. CIOs and CTOs can focus on meeting the quickly changing needs of internal and external customers to drive the business and growth forward and upward.

    That said, the pressure is on to deliver new code and new software solutions much faster, customer demand is relentless and escalating in intensity and speed. There is an almost immediate need that has to be fulfilled each and every day. And only automated and continuous delivery of code can meet that need in businesses of all sizes. It’s clearly a competitive imperative – and one that businesses must now approach differently as demand for “now” replaces demand for “perfect”. I advocate building v1 fast, then building v2 right. This gets product in the hands of consumers quickly and allows the team internally to answer pertinent questions that impact the long-term success of the product including:

    • How quickly will the data grow?
    • How fast will writes need to be?
    • Will it be feasible to write directly to the data store, or do you need a queue to manage

    writes?

    • What will the throughput be, and is it enough?
    • Will the system scale with usage?

    This “Lean Startup” approach to software development – which advocates fast iteration and data collection to hone in on the right product and requirements as quickly as possible – is all about figuring out what customers will use and then building those things.  And these same ideas can be applied to the technical ways we build products, too.

    Put another way – similar to creating a minimum viable product (MVP), build the minimum viable technical implementation that meets the business goals (the product can meet current usage requirements and performance).

    Most engineering teams have been taught to think about the software design and architecture from the beginning and build something that can scale. However, if you don’t have any customers yet, scaling really isn’t your challenge.  So, in some ways, designing for scale when you don’t have to scale yet, is solving the wrong problems.

    Of course, I am not advocating doing something careless, or writing bad code, but don’t over- engineer or solve for problems until you have them.

    In many ways, this process is about looking at the problems differently, and instead of solving the “big” problem, focusing on speed and efficiency – getting the highest ROI (return on investment) for your development resources.

    So you modify your development process to ship the first version quickly, and then once the v1 is out in the wild, plan to start on the v2 right after.

    Then your v2 can address all the problems with the first version of the product. You can improve the usability, cut or add features based on customer usage and feedback, pick the right technology and libraries to power the product, and spend time writing acceptance tests and unit tests that are unlikely to change. And, from a business perspective, you get the product out there faster, so it is easy to understand if it is going to drive revenue and success.

    This process makes sense because it:

    • Reduces the risk of over-engineering
    • If you build the wrong thing you can correct it
    • Chances are you will get to market faster

    So what are the downsides?

    • Total time to build is more than if you just got it right the first time. And operations can be a headache.


    If you do embark on this journey, here are some pointers:

    • Get management buy-in
    • Measure everything
    • Understand that the v2 will take much longer than the v1 and set expectations accordingly
    • Have a tight feedback loop with your customers
    • Make sure v1 and v2 are celebrated equally

    This is the formula organizations need to follow to be more competitive in today’s business of environment of rapidly evolving technology.