Category: Enterprise DevOps

  • SecDevOps is the Solution to Cybersecurity

    SecDevOps is the Solution to Cybersecurity

    Anybody paying attention to world news will notice that the threats and risks perpetrated by cybercriminal actors, in many forms, is a serious problem on the rise, affecting individuals, organizations and nations daily. The cybersecurity threat space is indeed alarming and growing rapidly. The cybersecurity solution space is struggling to keep up. After all, there is no such thing as 100% security.

    What is the Solution to Cybersecurity’s Problem?

    In my opinion, the industry has long underestimated the problem of cybersecurity, which has resulted in solutions that do not sufficiently stand up to the cybersecurity threat space. What is clear is that solutions must come from rapid software changes that detect and plug security holes as fast as they are found, and continuously deploy innovative defensive solutions that keep bad actors off their guard. To do that requires Agile and DevOps continuous delivery practices coupled with a security-aware mindset.

    What is a Security Aware Mindset?

    To put things in perspective, it is useful to consider the mindsets of design, QA, operations and security.

    Design mindset – create a product or service that customers want, now. The Agile framework addresses this requirement.

    QA mindset – verify a product or service works the way customers expect it to, when it is released, for all production configurations available at the time of the release. The DevOps framework addresses this requirement.

    Ops mindset – ensure a product or service continues to work the way customers expect, for all production configurations, for the life of the product or service. The site reliability engineering (SRE) and ITIL frameworks address this requirement.

    Security mindset – defend valuables for organizations that create or use a product or service against unintended and malicious actions, by people and organizations, both inside and outside of the organizations, for all production and non-production configurations, for as long as there is something of value to protect. The DevSecOps framework was created to address this requirement; as we have seen, this does not yet offer sufficient safeguards for the growing cybersecurity threat problems.

    The security mindset has multiple additional vectors of thought required compared to the design, QA and ops mindset. This helps us to understand why the cybersecurity problem space is bigger and requires more comprehensive solutions.

    Not long ago I considered security assurance to be a subset of testing practices. In 2016, in my blog, “Seven Pillars of DevOps – Essential Foundations for Enterprise Success“, I did not break out security as a separate pillar. At that time, this type of thinking was typical of developers. Security was someone else’s job. Perimeter defenses were deemed sufficient.

    Soon after, I realized that way of thinking was naïve on my part. By the time that I co-authored a subsequent blog, “Nine Pillars of Continuous Security Best Practices,” I added a separate pillar for security specific practices, and also added security practices within each of the other pillars.

    In parallel, DevSecOps became a thing in the DevOps world. The idea of integrating security practices into DevOps makes a lot of sense, because DevOps is the answer to continuous delivery of software, and security needs continuous delivery of defensive solutions. However, simply adding security to DevOps is not a sufficient solution, because DevOps was conceived to address specific problems associated with design, QA and Ops – not security. Simply adding security as another metric for releases is not enough. What is needed is a re-think of how DevOps can be used to deliver continuous security, as indicated in my book, “Engineering DevOps.” This is the same idea behind what is referred to as SecDevOps.

    In my opinion, it is now time for SecDevOps to gain favor over DevSecOps when it comes to integrating security practices with DevOps practices. This represents a much more significant shift than simply putting security first in the name. With SecDevOps, security concerns within the entire development organization and at every stage in the DevOps value stream, are explicitly prioritized over other types of concerns. This makes sense, given the much wider blast radius of security events versus other quality concerns that DevOps was originally designed to address.

    With SecDevOps, security tools and resources are weighted at the highest priority level. SecDevOps and secure coding practices are required training for application developers. Threat modeling is part of the value stream. Security tasks that are required to mitigate security risks are given the highest priority in backlog planning. At each stage in the DevOps pipeline, security concerns rise to the top of the priority list. Release and deployment readiness are weighted at the highest level. In short, SecDevOps explicitly plugs some important security holes that are not covered by DevSecOps. With SecDevOps, security becomes continuous, not just an add-on to DevOps.

    What This Means

    By explicitly plugging some important security holes that are not covered by DevOps or DevSecOps practices alone, it makes sense for SecDevOps to now emerge as the preferred framework to close the gaps between the growing security problem space with the evolving security solution space. SecDevOps offers the required security-first mindset and solves the need for rapid software changes that detect and plug security holes as fast as they are found, and continuously deploys innovative defensive solutions to keep bad actors off their guard.

  • Why We’re Swimming in Dashboards and Drowning in Data

    Why We’re Swimming in Dashboards and Drowning in Data

    Knowing how to use a dashboard is table stakes in the enterprise. Information technologies generate countless volumes of data from multiple sources, and dashboards are meant to harness all of that information, reduce the noise and display the stats you need to do your job. Yet businesses are still struggling to unlock the value of their data, with over half of global businesses (57%) claiming they can identify and capture just 70% of their data, according to a study conducted by IDC and commissioned by Qlik.

    As in “The Rime of the Ancient Mariner,” there is water, water everywhere, but not a drop to drink. Enterprises are inundated with dashboards and still struggle to make effective decisions with the information in front of them.

    The Limits of Analytics

    There are many reasons why a dashboard may communicate ‘bad’ or ‘useless’ information. Analytics can’t do it all. A data pipeline may be parched with too little data or flush with the wrong kind of data, limiting the volume and/or value of outputs that can be drawn into the dashboard. The organization may be heavily siloed, rationing the range of information available to the dashboard. Or, the tooling itself might be inadequate for leaders to quickly respond to opportunities and disruption.

    When a decision-maker looks at a dashboard, they want to see things as they could be, as well as how they are. That requires a dashboard that depicts the data itself, but that also generates views of, for example, how it looks when sales activity in the Southwest is increased in the face of a weather event or other externalities. Results don’t have to be taken at face value – they can be analyzed more carefully and intuitively to uncover meaningful insights.

    Investigatory analysis is what modern, interactive dashboards and applications are all about. They support non-linear exploration and search and provide advanced features, such as augmented analytics, to help subject matter experts explore data and generate insights without relying on IT, data scientists or expert analysts. Interactive dashboards also make it possible for business intelligence to be truly self-service, simplifying aspects that were once limited to experts working in much more complex environments. They give all employees access to the insights they need to make better decisions, regardless of their skill level, essentially democratizing analysis across organizations.

    How to Choose the Right Dashboard

    For any business looking to really expand decision making across the business, here’s how to find a dashboard suited for investigatory analysis:

    Accessibility and timeliness: In the past, business users who wanted insights had to submit a request to an analyst, wait for their turn in the queue and go back and forth answering clarifying questions before they could review a dashboard and make decisions. The process took too long, and insights came too late. With modern, interactive dashboards, users can explore all their data using interactive selections (filters), search, and NLP (natural language processing) powered by AI. In the end, they can ask and answer all their questions leading to informed decisions.

    Flexibility: Modern dashboards are not just static displays of content with limited filtering. They are rich analytics applications that provide unmatched interactivity and exploratory power. Business users aren’t limited to rigid, linear analysis on partial subsets of data. Instead, they have the freedom to explore all their data however they like. Analytics are always in context together, giving users peripheral vision, and all data relationships are exposed – including what’s related to your selections and what’s not.

    Performance: Interactivity should be driven by outcomes. Novel techniques to optimize and store data, index and understand relationships and deliver high-performance calculation all help to go beyond the limits of query-based and RDBMS architectures. Interactivity should also be enhanced with AI to deliver next-level analytical power, in new forms, across a full range of user experiences.

    A Crucial Tool in the Stack

    Turning data into business value is what a dashboard should—and can do—for the business. When a business user looks at a static dashboard or visualization, they usually end up with more questions than answers. To make an informed decision, they need to go through a process of questioning and evaluating – and then questioning again – an interactive display of business-critical trends until the right insight is fully uncovered. This iterative process is unique to every user and their lines of thinking, and modern dashboards allow all users, beyond data experts and analysts, to build visualizations and queries.

    In addition to creating business value, interactive dashboards help rally key stakeholders in organizations and allow them to act quickly to changing market needs. Take, for example, a major luxury fashion retailer; parent company of three well-known apparel brands. Their businesses hinge on having the products consumers want and need, when they want and need them. Their assortment planners need to analyze their sales mix and inventory mix by product attribution to identify mismatches and, more importantly, understand the drivers behind the mismatches to make more accurate inventory recommendations. Interactive dashboards allow them to investigate their data in different ways and ultimately inform strategic decisions for the business moving forward.

    In addition to empowering users to transform data into business value, dashboards ultimately drive the need for data literacy. Sharing dashboards throughout all levels of an organization fosters a data-driven culture by encouraging exploration of data – and that’s how new discoveries and innovations can be made.

    So while some say the dashboard is dead, I say long live the interactive dashboard.

  • Survey Illuminates Long Dark Road to Hybrid Cloud

    Survey Illuminates Long Dark Road to Hybrid Cloud

    While hybrid cloud computing will play a critical role in enabling digital business transformation it turns out most IT organizations lack the skills and technologies required to achieve it.

    A survey of 108 IT executives conducted by the research firm Pulse on behalf of CloudBolt Software, a provider of a cloud management platform, finds 94% believe hybrid cloud computing will be critical to digital transformation. A total of 92% also noted that empowering end users through self-service IT is a digital transformation accelerator, while 99% said successful automation depends on streamlining integrations.

    However, 78% of respondents said they lack the visibility necessary to optimize cloud deployments. More than half (56%) believe that their self-service offerings fail to meet user needs and more than three-quarters (76%) still rely on some form of custom coding when it comes to integration.

    In terms of the capabilities respondents are looking to acquire, 80% noted they want real-time insight into cost optimization and security remediation. A total of 71% want self-service to be easy for end users, while 62% want an approach to integration that doesn’t require deep domain knowledge or special expertise.

    CloudBolt CEO Jeff Kukowski said the biggest immediate obstacle when it comes to hybrid cloud computing is the lack of visibility IT organizations have into their existing IT environments. IT teams are not going to be able to unify the management of distributed IT environments without it, much less achieve anything approach observability, noted Kukowski.

    Pressure on IT organizations to accelerate application development while simultaneously reducing costs rose as the economic downturn brought on by the COVID-19 pandemic began. The challenge is that each new platform adopted by an organization tends to increase the total cost of IT as organization acquire tools and hire specialists to manage those platforms. It’s not likely all those platforms will be managed via a single console, but Kukowski said it’s clear IT organizations are moving toward a more federated approach that will enable them to centralize the management of IT.

    In the meantime, Kukowski noted organization are collectively wasting billions of dollars on IT platforms that are employed inefficiently. Most of that waste stems from either overprovisioning of IT infrastructure, or simply because someone didn’t think to turn off a virtual machine left running on a cloud service.

    It may be a while before IT organizations are able to strike that perfect balance between flexibility and control that currently remains elusive. However, organizations that focus on improving a few small things today will find themselves in a much better position to manage what is rapidly becoming an over extended enterprise tomorrow. Right now, Kukowski estimated only about a quarter of IT organizations have the sophistication required to manage a hybrid cloud computing environment.

    There’s no doubt the management of IT will become more automated in the months and years ahead. The challenge organizations face today is determining what tasks either can or soon will be automated. Once that’s determined, it becomes a lot easier to identify what DevOps skills those IT teams will require tomorrow.

  • 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.

  • More and More Enterprises Go Headless

    More and More Enterprises Go Headless

    IT faces high expectations for building and supporting omnichannel digital experiences. Simultaneously, web developers hold an evolving toolkit of architectural approaches to deliver content. One such framework gaining mindshare is headless, a style that decouples front end user experiences from back end application logic.

    Legacy options for content delivery can be somewhat cumbersome in that they don’t apply well to scenarios beyond websites. On the other hand, a headless framework uses web APIs to communicate with clients, making it a more adaptive model to support new devices and use cases.

    WPEngine recently released global research on the state of headless. Below, we’ll review the top findings from The State of Headless: A Global Research Report. I also met with Matt Landers, developer relations manager, and Jason Bahl, principal software engineer at WPEngine to discuss the evolution of headless and its future implications for developers.

    What is Headless?

    First off, what is headless? Headless decouples the front end from the back end, thus separating the user interface (UI) from the data and code that powers it. The headless movement represents a shift from traditional content management systems (CMSs) such as WordPress, Squarespace and Wix.com. These platforms are less extensible, as they intrinsically unite the back end with user-facing representations. Traditional CMS is “typically not that easy to scale,” noted Landers.

    Headless challenges the status quo by offering more flexibility. As headless adopts API-based content negotiation, it could essentially deliver highly personalized experiences to any connected device. This could help support emerging platforms, like mobile, voice assistants or augmented reality (AR).

    Simply put, headless is “a CMS that is not responsible for rendering the site,” Landers explained. “What attracts people to headless is component-based architecture and the ability to build isolated components,” he added. For example, a headless framework could include an author bio component that is reused in any custom style across devices. By deploying to a CDN, headless could enable high-speed performance, as well.

    Headless Adoption Surges

    Interest in headless is increasing across the board. Currently, 64% of enterprises surveyed adopt a headless approach, representing about a 25% increase from 2019. Furthermore, headless use is expected to grow: over 90% of organizations not currently using a headless setup plan to evaluate a headless option in the coming year.

    The strong interest in headless likely represents a growing necessity for large enterprises to support various digital channels in a consistent manner. In fact, 92% of organizations credit headless with delivering a more consistent content experience, the report found.

    Benefits of Headless

    A key benefit to introducing headless is the decoupled nature of the approach. This makes it possible to support multiple platforms, such as websites, mobile apps, IoT devices, connected kiosks, smartwatches, voice assistants, AR and virtual reality (VR) from the same source.

    Respondents also cited additional benefits to adopting headless such as increased performance, quicker time to market and rapid innovation. These positive attributes make sense because, with headless, applications only request the data they need. Therefore, headless could certainly facilitate more dynamic applications and custom-tailored user experiences. If used effectively, headless setups reduce bloat to create fast-loading digital experiences that further the SRE agenda.

    Tech Choices and Use Cases

    An average organization is spending $2.6 million on their headless implementation, found the report. So, what are they spending it on? Well, some common headless frameworks and SaaS platforms include Contentful, GraphCMS, Atlas, DatoCMS, Cosmic, Netlify, Sanity.io and Prismic, among others.

    While the report didn’t query respondents on their exact headless stack, it revealed a general satisfaction with headless solutions, with relatively high net promoter scores (NPS). When selecting a headless provider, respondents tend to consider performance (41%), e-commerce (35%), scalability (33%) and APIs and extensibility (30%).

    Though headless spans many use cases, e-commerce is clearly a primary use case for the headless stack, with 51% of respondents adopting headless to support e-commerce. Other top use cases for a headless approach include a website (52%), IoT (47%) and progressive web apps (40%).

    Drawbacks of Headless

    Though headless provides impressive malleability, it does require a shift in thinking, and implementors must inevitably overcome certain drawbacks. API security, for example, is at stake as API attacks and threats increase.

    Headless could also require additional administrative burden in terms of data integration and upkeep. With headless, instead of using plugins, IT must enlist front-end developers to integrate data and build front-end behaviors. Debugging a decoupled front end and back end can also be an added development burden. “There is an opportunity in the headless ecosystem in general to mature the experience for the content publisher,” describes Bahl.

    Future of Headless

    Within today’s remote economy, most acknowledge that digital experiences are now crucial to supporting business at large. In fact, 92% of organizations believe digital experiences are vital to their organization’s success, found the report.

    Headless architecture promises to retain a stable back end to support these escalating digital demands — especially useful considering the ever-changing nature of front end clients. On that note, the report found that 32% and 31% of respondents adopt headless for VR and AR experiences, respectively. Therefore, the headless approach appears to be a valuable technique to future-proof current investment against emerging digital trends.

    The State of Headless: A Global Research Report, conducted by Vanson Bourne between January and February 2021, surveyed 400 IT/technical employees with knowledge of headless. For more insights, you can read it in full here.

  • How to Spot SRE Adoption Barriers

    How to Spot SRE Adoption Barriers

    It’s no secret that site reliability engineering (SRE) adoption is growing. The operating model, it seems, is pivotal for digital transformations across the enterprise. According to the Upskilling 2021: Enterprise DevOps Skills Report, 22% of respondents (up 7% from last year) cited SRE as the approach they need to continue automation in 2021.

    Common Adoption Barriers

    However, for some companies, adopting SRE principles and practices isn’t always easy. Ahead of the upcoming SKILup Day conference focused on SRE (Register for SKILup Day: SRE here), I asked several DevOps Institute Ambassadors and SRE subject matter experts to provide insights into the barriers of SRE adoption. Here’s what they shared:

    Marc Hornbeek, CEO and Principal Consultant at Engineering DevOps Consulting and author of the book, “Engineering DevOps”

    “The primary barrier for SRE adoption is executive vision and team alignment around a goal to transform to SRE practices. SRE affects the entire organization’s practices, roles and investment priorities. Without an executive sponsor, SRE transformations are not going to go far.”

    Stephen Walters, Solution Architect at xMatters, Inc.

    “Culture, and in particular, cultural change, is the greatest barrier to SRE adoption. As much as everything about the human race, the things that got us to being the creatures we are today, is about evolution, which is change, and we are not particularly good at it. Or, more specifically, the bigger the change, the more resistant we are to it. It has always been a great oxymoron in IT philosophy that in order to “transform,” you must change, but that transformation is occurring because we are not good at change. So it was with agile in the early days. Organizations wishing to transform to agile (small, iterative change) would do so under a transformation project, which would typically be waterfall (big bang). Big change, big cultural resistance. The key is to implement transformation in smaller, agile chunks. They are more easily accepted and testable, and also easier to roll back or adapt if they do not work or are not acceptable. All of the benefits of agile development apply to agile transformation.

    The second greatest barrier is, then, “buy-in,” where the simple answer is, unfortunately, show the end user “what is in it for them.” This will typically override the enterprise-scale view of “what is in it for us?” but, over time, with any cultural transformation, this is one of the things that should change, iteratively, and also be a focus for developing a more holistic and empathetic culture.”

    Shivagami Gugan, Chief Technology Officer at CX Tech Unicorn

    “Any organization, irrespective of whichever level of maturity they currently exist on today, can adopt SRE and improve their business outcomes. However, the key underlying principles of SRE and its applicability should be understood properly. There is a lot of hype around transformation and the first barrier is about understanding what SRE means within your organizational context. I find most of the time, people try to imitate what highly mature companies like Google or Spotify or some other cloud-born company does, and this usually results in failures. SRE is the purest form of the implementation of DevOps. SRE is about removing the silos in a product life cycle to achieve business outcomes in a safer, faster, cheaper and better manner. If this is understood clearly, the first barrier gets removed.

    The second barrier is this complicated vision of boiling the ocean – doing 100% Agile, 100% DevOps or 100% SRE. This doesn’t work, especially when you have heritage systems of records, on-premises services and heritage infrastructure and a whole lot of baggage built over several years (sometimes decades) which is the usual case for most companies. So be very clear in choosing target areas.

    The third barrier is when you think SREs specialize in building operational reliability, but do not have anything to do with the development or the deployment phases of the life cycle. Reliability is everyone’s problem – the technical product manager, the developer, the tester, the support engineer; not just the SREs. The reality of the SRE role is to ensure services availability and reliability by supporting the other teams that own these services. SREs are enablers, they are collaborators, and their goal is to ensure that the services are overall resilient, reliable and that incremental value is delivered in a continual manner. When an organization understands that implementing SRE is an underpinning cultural change that affects all parts of the organization, then it becomes easier to remove the main barriers.”

    Lisa Chan, Head of Software Engineering & DevOps at PETRONAS

    “Not all organizations have the luxury of having an Ops team composed of skilled developers, which is a key success factor for the adoption of the SRE working model. In my case, I’m in an IT organization of 1,800 folks that has supported an oil and gas company since its inception 40 years ago. We serve a captive market of an integrated energy business with more than 100 companies under its portfolio. As a result, there is a legacy landscape of more than 2000+ applications. The IT organization still maintains the common “Dev is Dev, and Ops is Ops” anti-pattern. Even though we are in transition towards a working model that is more collaborative, it is unrealistic to expect our 300 Ops personnel to reskill themselves to be developers, because many of them have traditional skill sets along the typical Ops silos; e.g., networking, database admins, server admins, data center management, call center agents, etc.”

    BMK Lakshminarayanan, Value Stream Architect at Bank of New Zealand

    “Building the SRE practices and skills within enterprises are always challenging, as some are still embroiled with old ways of thinking. The thinking, associated techniques, available tools and limited skills are constraining SRE adoption in most enterprises.

    Renaming the system admins to SREs neither helps nor makes SRE experts. Investing in expensive tools doesn’t help, either. Any adoption and transformation is a gradual process. A typical medium to large enterprise has a few hundred systems, applications and services with various operating systems to support, database platforms to manage and hundreds of application databases to monitor or administrate. To this complexity, add all the dependencies of other services and components, as well. Hence, redefining the SLOs, SLAs and SLIs for these services, automating everyday maintenance tasks, understanding the toil, building resilience and fault-tolerant characteristics within these systems and applications are uphill tasks for most enterprises.”

    Identifying Other Common Adoption Barriers

    Many other common barriers for enterprises are:

    • Availability of up-to-date system and application information in a centralized platform
    • Observable nature of legacy systems
    • Understanding the dependencies and service levels (Promise Theory)
    • Availability of the right tools for the right job
    • Skills – old ways do not open new doors.
    • Time – time and space for people to upskill, train and experiment.

    Want to learn more about SRE and how to overcome these adoption barriers? Join us for SKILup Day: Site Reliability Engineering on May 20. Register here: https://devopsinstitute.com/sre-2021/.

  • DevOps Practices Gap Assessment

    DevOps Practices Gap Assessment

    Using DevOps to continuously deliver software has proven value for organizations that are on a path towards digital transformation and continuous improvement. To get the maximum value from DevOps, it is important to use recommended best practices, inclusive of people, processes and technologies. A gap assessment is a great way to efficiently evaluate an organization’s practices for DevOps, and determine a strategy for improvement. Gap analysis provides valuable inputs for formulating a strategy and roadmap to improve a topic including DevOps.

    My SlideShare, Gap Survey, Assessment and Analysis For DevOps, explains how my Nine Pillars Gap Assessment Tool greatly speeds up the gap survey, gap assessment and gap analysis process for DevOps.

    It is important to clarify a few definitions for this blog, because I have found that different people and organizations use these terms differently. In this blog, and in my consulting work, I use the following definitions.

    • Gap survey is a discovery tool used to collect information about the current state of practices for a topic.
    • Gap assessment is a process to determine differences (gaps) between current practices and recommended practices for a topic. Gap assessment is also used to refer to the entire collection of activities in this list.
    • Gap assessment workshop is a meeting in which the gap assessment is validated prior to gap analysis.
    • Gap analysis is the process of determining priorities for reducing gaps found during a gap assessment.
    • Gap assessment tool is software that helps perform gap surveys, gap assessments and gap analysis.

    For those that want to dig deeper on this topic, additional definitions and contextual information related to the way I do gap assessments are clarified in my book Engineering DevOps.

    I define a seven-step process for gap assessments. The steps are as follows:

    1. Pick a topic to analyze. The same processes and tools can be applied equally well to almost any topic.
    2. Determine recommended practices for the topic. Something that is worth doing a gap assessment for, such as DevOps, will normally be fairly complex with dozens, if not hundreds of practices. Categorize the practices into groupings (I call the groups “pillars”) to make the list of practices more understandable and meaningful. To do this will require some research and work. For example, I have a database of practices and pillars for DevOps, continuous testing, DevSecOps and SRE and some other topics such as DevOps.
    3. Enter the practices from step two into a gap assessment tool. The tool can be a simple survey tool you create, a commercial survey tool or something custom-made.
    4. Determine who needs to be included in the gap survey.
    5. Collect data using the gap survey.
    6. Perform a gap assessment.
    7. Perform a gap analysis.

    For the remainder of this blog, I explain the above seven steps for DevOps.

    Step one: Pick a Topic to Analyze
    In this blog, the topic is DevOps.

    Step two: Determine Recommended Practices for DevOps
    For an example DevOps assessment, I used the practices under the nine practices categories described in a blog that I co-authored called Nine Pillars of DevOps Best Practices. The nine practice category pillars are:

    • Leadership
    • Collaborative culture
    • Design for DevOps
    • Continuous integration
    • Continuous testing
    • Continuous monitoring
    • Elastic infrastructure
    • Continuous delivery
    • Continuous security

    Step three: Enter the Practices from Step Two into a Gap Assessment Tool
    A gap assessment tool, pre-loaded with a sample of DevOps practices, in a file called DevOps Assessment, can be downloaded for free from one of the resource pages found on my website Engineering DevOps. You can edit the practices categories and add/delete practices from each category if you prefer to make changes.

    Step four: Determine Who Needs to be Included in the Gap Survey
    For the gap analysis to be comprehensive, people in roles that are affected by DevOps practices need to be surveyed, or at least represented, to ensure their perspectives are included. The following are example roles that typically are included.

    • Business leaders – because they influence culture and budgets for DevOps.
    • Developers – because they need to design in accordance with DevOps practices.
    • Project owners – because they influence product work priorities.
    • QA testers – because they need to test in accordance with DevOps practices.
    • Ops – because DevOps practices affect operations.
    • Security – because DevOps affects security practices.

    The survey can be conducted for an individual application, a group of applications, or all the applications in the enterprise. However, it is important that the gap assessment and gap analysis be performed on the organization segment that is being targeted for improvement.

    Step five: Collect Data Using the Gap Survey
    A gap survey should allow each surveyed person to enter an importance level score, a practice level score and comments for each practice. All this information is essential for the gap assessment and gap analysis. In the gap survey included within my gap assessment tool, survey respondents are asked to score the importance of each practice as one of 0=not relevant, 1=not important, 2=nice to Have, 3=important, 4=very important or 5=critical. Practice level choices are 0=not sure, 1=rarely, if ever, 2= sometimes, 3=most of the time, 4=always or 5=We are really good at this. Comments that are relevant to qualify or explain the scores entered for each practice should also be entered, especially if there is any doubt or ambiguity.

    Step six: Perform a Gap Assessment
    The gap assessment process requires all the practices scores collected from the surveys to be collected and assembled to calculate an aggregate set of scores. Gap scores are calculated using a formula that weights each practice level score with the corresponding importance level score. A visual representation helps to identify practices areas and individual practices that have the highest, most important gaps.

    No matter how professionally written the practices and score definitions are, it is not unusual for some people to misunderstand and to enter scores that they would not have otherwise. For this reason, it is important to ensure that the data collected is validated before conducting the gap analysis. The preferred approach is to conduct a gap assessment workshop with key representatives from each role that participated in the survey. During the workshop, the scores for each practice that have a high deviation between survey responses are discussed and, if necessary, adjusted.

    Step seven: Perform a Gap Analysis
    The gap analysis process involves extracting the high gap practices and tagging and ranking each of them against solution categories determined by a consultant or topic expert.

    The results of the gap analysis indicate where solution strategies and implementation roadmaps need to be focused to reduce the most important gaps.

    What This Means

    While it is true you can easily stand up DevOps tools quite quickly, this alone will not realize the benefits of following effective and safe DevOps practices. Those who are serious about DevOps will do well to learn from others, and be serious about using recommended DevOps practices. This blog explained a gap assessment approach, which uses my nine pillars of best practices for DevOps. My free DevOps gap assessment tool facilitates getting a gap analysis for DevOps and priorities to improve DevOps practices for an organization.

  • ‘Old Man Yells At Cloud’

    ‘Old Man Yells At Cloud’

    These days, software programmers are increasingly estranged from hardware. Most millennials and Generation Z developers have never had to mount physical servers. They have never been lulled by the gentle hum of a server room chugging along in synchronous harmony. Today, you don’t even necessarily have to build your own PC or worry too much about disk space.

    Instead, cloud-native software developers conveniently offload the server burden to cloud service providers (CSPs). Hosting in a cloud, like AWS or Azure, for example, makes a lot of sense — it allows programmers to hone in on their own specializations. Elastic computing models are cost-effective for startups, and CSPs typically offer a vertical stack with helpful integrated platform-as-a-service (PaaS) and software-as-a-service (SaaS) offerings. However, what are we sacrificing?

    Well, first, research shows the cloud model becomes less cost-effective as a business scales. Second, as more companies transform into technology platforms, cloud usage could better enable their competition. Third, more direct access to bare metal could be an attractive option for certain service providers to increase ownership and control workload optimizations.

    These arguments are bolstered by large companies such as Dropbox, Facebook, Walmart, and others that chose to cut their cloud allegiances in favor of building their own data centers or adopting colocation (in other words, running your own hardware in someone else’s data center, also known as “colo”).

    I recently met with Zach Smith, managing director, bare metal, Equinix, to understand the current state of hardware-as-a-service and the future of hybrid server models. He believes that in the coming years, improved interfaces that access low-level infrastructure will arm IT with better consumer choice that brings them closer to the metal. Yet, to enable this, the hardware world will need to take some lessons from the upper stack regarding transparency, open source community, programmability and improved developer experiences.

    Sidestepping the Cloud

    Public clouds arose as a convenient one-stop-shop to host entire software application environments. As a result, “we have a generation of developers who will never physically touch that hardware,” Smith said.

    The cloud infrastructure services market was worth $39.8 billion in Q4 2020, estimates according to estimates from Statista. Having witnessed the “movement toward verticalization of hyperscale clouds,” Smith now sees the infrastructure-as-a-service (IaaS) market as an industry of high margins and escalating fees. This is echoed by others who seek to reduce rising cloud expenses.

    Though cloud computing usage is growing considerably, the data center isn’t dead. Instead, computing models are morphing and becoming hybridized. “By 2025, 85% of infrastructure strategies will integrate on-premises, colocation, cloud and edge delivery options, compared with 20% in 2020,” predicts David Cappuccio, distinguished VP analyst, in a Gartner report.

    As hybrid multi-cloud approaches emerge, Smith notices a resurgence of attention being paid to infrastructure. Some massive service providers are starting to construct their own data center estates; others, such as Box, now own and lease servers from data center providers.

    Benefits of Bare Metal

    As mentioned above, there are a few reasons to move back to the metal. First, it may simply be more cost-effective for large deployments. In his well-researched article, Antoine Beaupré compared monthly recurring costs for colocation versus an AWS bill, and found the break-even point rested at $100,000 per month, or 150 Amazon m4.2xlarge instances. His research also found that I/O-heavy applications are more costly in the cloud than via colocation.

    “While many services simply launch in the cloud without the organizations behind them considering other options, large content-hosting services have actually moved back to their own data centers,” Beaupré said.

    In addition to cost savings, automating colocation with a programmable layer could also offer more fine-grained control over computing optimizations. “I believe what we’re creating is an operating model for a rapidly changing hardware substrate,” said Smith. He described how bare metal opens up a neutral infrastructure substrate to control physical networking aspects such as cross-connects, IP transits and peering — a benefit Smith half-jokingly called ‘NetDevSecOps.’

    Another argument is that investing in hardware could, ironically, bring sustainability benefits. A report conducted by ITRenew estimates that, of the total embodied energy required within a server’s entire lifespan, 77% is used to manufacture the hardware itself. In contrast, the operational energy used over a server’s lifetime only accounts for 22%.

    Thus, there is an environmental benefit to reversing the trend of a make-dispose economy continually producing new servers. Instead, hardware ownership could encourage a more circular economy. “A circular economy aims to end our take-make-dispose economy, which is a very linear approach, and instead, keep products at their highest possible value for as long as possible,” according to the ITRenew report.

    Learning From the Upper Stack

    How can we build a fundamental non-opinionated infrastructure platform? According to Smith, the industry needs “hardware and networks that are programmable and usable by a developer generation.” To Smith, changing firewalls at a kernel level, altering how the runtime works or controlling the IP stack, should all be operational via API commands.

    Yet, hardware accessibility is still rather opaque and, historically, not as developer-friendly. “How can we take abstraction and community-driven ideas from up the stack?” Smith asks. To enable these changes, he believes the hardware world should model itself on the upper stack in a few key areas:

    1. Transparency: The hardware world is not as easy to comprehend. “When you get to the physical side of switches and routers, it’s still arcane,” Smith said. Increased transparency in functionality and ownership will be required to turn servers into something all developers can operate.
    2. Open-source community: In the same way the software world is built on strong developer communities, hardware will require an open community to normalize things like firmware, boot order and support for differences between drives.
    3. Programmability: “Self-service and programmability are requirements for most things these days — there’s no difference with physical infrastructure,” says Smith. Take the rise of the API economy — today’s mantra is, essentially, if something is possible in a UI, it should be possible through an API. Similarly, if it can be done in a server, it should be controllable with an API.
    4. Quality developer experience: Self-service, programmable infrastructure is just the beginning — interfaces to operate infrastructure require good developer experience. Smith feels that hardware requires an improved buying experience and better life cycle management capabilities. This could be enabled by open source tools like Tinkerbell, a provisioning and workflow engine supported by Linux Foundation.

    Back to the Metal — A Platformer’s Dream?

    All this is not to say the public cloud isn’t valuable – it absolutely is. The cloud has been necessary and has proven resilient enough to support online business and digital life as we know it throughout the pandemic and for years prior. “In 2020 and beyond, most organizations are going to be transforming into a completely cloud-based environment,” said Werner Vogel, CTO, Amazon, during an online AWS summit.

    But, even if most organizations are in the cloud, that doesn’t mean all of their assets will be. Service providers, especially, may cling to hybrid models for more control, to avoid supporting the competition and, perhaps, even to save money. Private data centers could also increase security. In an era where raw computing power is becoming a new asset (quite literally, in the case of cryptocurrency), the server rack is starting to look sexy again.

    “The magic happens when software and hardware work together,” said Smith. But, giving access to physical technology to a generation that has never touched it will require some ingenuity. As Smith says, this could be done by “automating colo” through more usable, standardized interfaces for hardware management.

    “We will see a future in next 10 years where operated software is separated from cloud infrastructure,” Smith said. That’s a bold statement, as such a dramatic change would, in effect, usurp the current cloud provider IaaS market share, altering the distribution and economic model associated with global software.

    While this dream may seem far-fetched, if more platforms decide to cut out the cloud middleman and go it alone, it could materialize.

  • Next Up: Portable CI

    Next Up: Portable CI

    One thing that we’re very good at in IT is breaking new ground, coming up with ideas that work astoundingly well, getting broad adoption, then standardizing them for interoperability. When a new technology (looking at you, cloud) has problems with standardization and interoperability, we find a way around vendors’ reluctance to give you freedom of choice. For cloud, for instance, we found another great technology – containers – that greatly limits our lock-in to a given cloud vendor’s fare. Of course, whether standards or workarounds are the answer we arrive at, there are always wrinkles. Vendors are certainly not motivated by interoperability; they want your regular cash infusions, and interoperability could be more of a drain on them than a feed of new customers. Particularly in today’s environment, where vendors sometimes think that doing “to” customers is an acceptable substitute for doing “for” customers. We have to work around things like “embrace and expand,” which is still very real, and deploying containers to cloud A versus cloud B still has a bit of vendor-specific work, but we have enough to get it done.

    As continuous integration (CI) has become critical to an increasing number of organizations’ IT processes, the time has come to do the same with CI tools. Standardization is a good first goal, but it is more difficult here than in many areas, because the topic is so broad. An app might be built in one tool and tested in another, or it might be built via the use of shell scripts while tested with a UI tool, etc. It is not an easy solution to build, but it is an idea whose time has come – particularly with the cloudification of the space. We now have full-on CI systems that are in the cloud, and which hook you in with custom instructions. We’ve already had one large DevOps vendor essentially tell their entire user base, “We’re moving you to the cloud, unless you pay these inflated fees,” and others that never offered options for traditional architectures at all.

    Yet, we know apps move from in-house to cloud (and though it is uncool to mention, move back), and organizations are motivated by cost containment and mobility more than by what their chosen vendor wants them to do.

    So, it is time for some bright company or OSS team to put together a standard and a tool that implements said standard. It will be a lot of work, to make portability between CI tools that came from widely disparate roots – some from build, some from test, some even from deployment. But we’ll be needing it. A while back, everyone was a Puppet shop. Now, it seems, everyone is an Ansible shop. In simple terms, everyone will inevitably be a [something else] shop, because nothing lasts forever. So, a tool providing CI mobility between tools will definitely have a market – smaller today, but eventually large. We don’t need Yet Another CI Tool, we need that portability.

    I’m sure it’s coming. History does offer glimpses of the potential future, and we’ve seen this cycle before. I’m just saying, the time is now, not five years from now. We can target the OS of our choice and the cloud vendor of our choice, using containers to simplify the differences in host OS/vendor. The ability to use the CI tool of our choice is the logical next step.

    I haven’t heard of a project or company working on this yet; if you have, drop me a link in comments or email (I prefer comments, so others can look at your suggestion too, but whatever works for you), and I’ll take a look. It would be cool to support this kind of effort, when it eventually comes about.

  • IBM Unifies Cloud Services to Simplify App Dev

    IBM Unifies Cloud Services to Simplify App Dev

    IBM announced today that an IBM Cloud Code Engine service that unifies the cloud platforms on which applications are built and deployed is now generally available.

    Built on top of a serverless computing platform, IBM Cloud Code Engine is a managed service that unifies access to a platform-as-a-service (PaaS) environment, a container-as-a-service (CaaS) environment and batch workloads, that run on traditional virtual machines, to a single platform.

    At the core of that managed service is an instance of Kubernetes running Knative middleware for invoking an open source serverless computing framework, the Istio service mesh and Tekton pipelines for building DevOps workflows.

    Jason McGee, CTO and vice president for IBM Cloud Platform, said the goal is to eliminate the artificial constructs that developers are forced to navigate in the cloud today that can each trace their lineage to a different era of software development. The IBM Cloud Code Engine unifies the developer experience in a way that makes it simpler to build and deploy applications on the type of cloud service that best makes sense for a specific application workload, McGee said. Developers no longer need to configure code for a specific type of infrastructure; they can simply describe how they want source code or a container image to behave, and IBM Cloud Code Engine automates deployments accordingly.

    The serverless computing framework that IBM Cloud Code Engine is built on also makes it possible for IBM to only charge organizations when code is actually running, versus requiring them to commit to a specific amount of infrastructure to run a set of virtual machines, McGee added. Charges are based on the memory and vCPU consumed and incoming HTTP calls. That approach will, over time, substantially reduce the total cost of cloud computing, said McGee.

    It should also accelerate the rate at which applications are migrating to the cloud, added McGee. Today roughly 20% of application workloads run in the cloud. Getting the next 40% of workloads shifted into the cloud will require providing a simplified application developer experience, noted McGee.

    The challenge organizations are wrestling with today is that they are deploying a mix of monolithic and microservices-based applications in the cloud that, to varying degrees, rely on batch-oriented and real-time platforms. IBM Cloud Code Engine represents an effort to provide a layer of abstraction over a wide range of cloud services that they can flexibly invoke via an event-driven platform, as required.

    The DevOps implications of IBM Cloud Code Engine are potentially profound. DevOps teams today spend an inordinate amount of time provisioning cloud infrastructure on behalf of developers. IBM is now making a case for a platform that automates that process in few seconds. In effect, control over cloud infrastructure will shift even further left to application developers. DevOps teams, in theory, will spend more of their time optimizing cloud environments after an application has been deployed.

    It’s not clear to what degree platforms such as IBM Cloud Code Engine might force cloud service providers to consolidate distinct cloud services they provide to developers today based on the type of application being built. However, it’s already apparent that the writing on the wall heralding that consolidation have now been indelibly inscribed.