devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Low-Code and DevOps: Friends or Foes?

    Low-Code and DevOps: Friends or Foes?

    What does low-code mean, and who is it really for?

    Over the last few years, I’ve seen many articles associating “low-code” with “citizen developers” or with people who don’t have deep development skills. Users can arrange visual elements, or fill in forms with key information and publish the result as an application.

    But tools for citizen developers are only one part of the low-code story. There is also a growing number of tools for professional developers, and I want to talk about those, too.

    Both citizen developers and professional developers have a role to play in application development and automation projects, and low-code has something to offer both of them.

    Low-code is Not a Market, it’s an Approach

    Low-code does mean providing visual and graphical tools and simple frameworks that mask more complex coded operations, so the application designer does not have to directly touch the code that performs desired operations. These apps are naturally limited, as the resulting application can’t be highly customized if you can’t touch the code.

    With these kinds of visual tools, anyone can create a simple application within the limits of the tool. But when we pull back and look at what is needed to create larger, more complex applications – ones that need to communicate with other enterprise systems, or need extensive customization, or cross organizational boundaries, or need to pay attention to governance requirements, for example – the visual-only approach is frequently insufficient. In complex cases, developer expertise is often needed, and developers have to get “under the hood” to tinker with code.

    There is no “low-code market.” We are bringing tools to people who need them to develop specific projects. A comprehensive low-code approach to application development and automation means offering both visual programming and coding capability. For usability reasons, these tools are clearly separated and presented to the development team in a way that allows citizen developers to work on certain elements and developers to work on others, all on the same platform.

    We know that it’s possible to serve professional developers with low-code, too. A low-code approach also includes drag-and-drop tools that developers can use – for example, to develop APIs, or to integrate the application with other systems, or to customize front-end interfaces. Of course, when code is required, developers should be able to use their own tools and frameworks and not be limited by low-code tools. Platforms that offer a hybrid approach are likely to be most useful to mixed-skills development teams.

    The Hybrid Approach

    Strictly low-code tools can serve simple automation use cases. More broadly, automation platforms offer a hybrid of low-code and coding capabilities for more complex automation use cases.

    For critical enterprise applications, both business and developer inputs are usually needed. Having tools for both of them means not leaving anyone out.

    Low-code tools will continue to become more mainstream. Low-code is not a fad or a passing trend, but a quiet revolution that will see greater incorporation into more business tools.

    Here Come the Digital Natives!

    More vendors are offering low-code tools for digital process automation, business intelligence, robotic process automation, identity management and data integration, to name just a few.

    As automation platforms and other low-code tools mature, a greater number of people are getting used to working with them. Developers are less hesitant about incorporating non-developers into their teams, as everyone gains a better understanding of the benefits of these platforms.

    The younger generations entering the workplace today are digital natives. They are fearless about diving into technology and working hands-on. So, these low-code tools are ready for them, and they are ready to put them to work.

    Low-code is breaking down technical barriers to work in the automation space, making smooth collaboration between business and development easier.

    Low-Code Can Be a Double-Edged Sword

    Automation and development teams are also becoming more aware of vulnerabilities and compliance issues as citizen developers roll up their sleeves and join the technical team.

    Low-code tools are a double-edged sword. They facilitate teamwork, but issues with security and data governance may not be top-of-mind for non-developers. If you have a big team working on automation and/or application development and delivery, the need to build in governance becomes even more important.

    Using a shared platform will help manage and mitigate these issues with security and governance. This will become even easier as the platform tools evolve and mature, so DevOps teams can use them to help mitigate some of these issues.

    Does Low-Code Have a Place in DevOps?

    We are definitely seeing the impact of low-code on development environments and DevOps. Remember, low-code started with small applications, and while DevOps-style teamwork and workflows may not be needed there, as the use of low-code platforms becomes the norm for critical enterprise projects, DevOps will be a necessary part of the mix. This is where low-code is having a more obvious impact; Agile methodologies using low code platforms for iteration, for continuous improvement and for continuous delivery. These applications aren’t one-and-done. They need to be maintained, improved and delivered, again and again.

    Low code isn’t going away. On the contrary – it’s going everywhere.

  • 4 Ways to Overcome Agile Transformation Obstacles

    4 Ways to Overcome Agile Transformation Obstacles

    If an organization desires a successful Agile transformation, the first step is to shift its thinking from ‘doing Agile’ to ‘being agile.’ Unfortunately, a commonly shared belief that Agile is just a software development methodology keeps too many companies stuck in the ‘doing Agile’ mindset.

    This belief ties back to the principles of Agile thinking from frameworks like Scrum or Lean. Most of these methodologies were focused on teams of developers. Naturally, the vocabulary and tools derived from these methods are unique to software development. While development has evolved away from waterfall approaches, the rest of the organization tends to run into cultural challenges downstream because the vocabulary and ways of working are foreign.

    When an organization begins to lose progress downstream, it is too focused ‘doing Agile’ rather than ‘being agile.’ In order to shift the mindset toward ‘being agile,’ a new mindset must be adopted across the organization. These four insights offer ways to overcome obstacles along the way:

    Instill Agile Thinking Across the Organization

    The first step toward instilling agile thinking is to establish common vocabulary and define what it means to be agile. A common vocabulary and understanding of agility helps teams across the organization understand and see that agility is more than doing sprints.

    As an organizational strategy, agility equates to flexibility – the ability to adapt to changing business requirements. It also means being collaborative and making complex processes more lightweight. Instilling this type of agile thinking into everyone at the organization leads to success. DevOps, for example, successfully instills this type of thinking through value stream management.

    Essentially, this hurdle boils down to setting common goals and creating a common understanding of what ‘agile’ means across the organization.

    Achieve Autonomy Through Self-Organization

    Agile frameworks encourage self-organization. When teams self-organize they are given a task to do. However, no one tells them how they’re going to accomplish it. A self-organizing team gains a certain amount of autonomy, which leads to empowerment.

    With self-organization also comes risk. The organization must learn how to embrace risk, how to look at failure as an opportunity to improve and how to empower teams in a more self-regulating way. When teams self-regulate and self-organize, it’s a team win when they are successful. This develops a sense of communal pride.

    When breaches or too many failures do happen in a self-regulating system, the policies and consequences naturally occur. However, the key differentiator is that these environments are not driven by the policies. Rather, the objectives drive the behavior. When objectives are being met, empowerment stands.

    Agile software development, DevOps and site reliability engineering (SRE) are intended to be self-regulating systems, but all first require leadership to create psychologically safe environments, blameless postmortems and more. There is no room for a blame culture in a self-regulating system, and the organization must be agile enough to meet the demands of the system.

    Leverage Intelligent Lightweight Process

    Agility does not equate to a complete absence of process. It means there is enough process in place to ensure consistency, improve flow between people and teams and that automation replicates the process simply and effectively.

    IT organizations must understand that it is possible to move away from complex and authority-based processes and continue to leverage an element of process.

    Intelligent Process Means Intelligent Automation

    Although humans are the driving force behind agility, automation helps them go faster with more consistency. However, there is no such thing as ‘being agile’ with automation alone. Agile cannot be bought, and it’s important to get teams thinking that way. Automation should complement Agile, but not define it.

    When investing in automation, a cost/benefit analysis is critical. When considering automation, think in terms of two key metrics: time and quality. With two equally important metrics, the organization cannot become dependent on one aspect or another.

    For example, you can’t go faster with a manual process. You also can’t go faster with only automation, because the automation alone doesn’t replicate your intelligent lightweight process. And, you can’t go faster just by having a process, because the process can become very bureaucratic.

    Process is just a means of getting there, but it needs people and automation to make the processes come alive. People, process and automation all play an essential role in creating an intelligent process.

    Successful Agile transformation is more a way of thinking and behaving than simply following a framework. From a human perspective, an organization that experiences true agility, as we’ve defined it today, allows humans to exercise their competencies, grow skills, collaboratively celebrate success and learn from failures.

    If you’d like to learn more about Agile Transformation, especially in regards to Agile Testing, you can register for the next SKILup Day on April 22. Please register for SKILup Day: Agile Test Management for the Enterprise here.

  • The Single-Sentence Postmortem

    The Single-Sentence Postmortem

    Do you have four seconds?  In the time it takes you to read this sentence you could be done with your incident’s postmortem.

    “But my postmortem has 8 sections!  I have to construct a critical timeline, restate my followup tasks, show the major milestones, evaluate root cause…”

    Stop right there.

    First of all, your incident management system should be automatically capturing your timeline, follow-up tasks and major milestones as they happen — so you shouldn’t be worrying about reproducing that content at all.

    Second of all, the most critical thing a responder can bring to a postmortem, in the moments right after the incident concludes, is the one-sentence personal context of what actually happened. It’s the same sentence they’d say to a co-worker in the lunch room when asked what went wrong. But to achieve organizational resilience, the knowledge in that sentence has to be captured and distributed. I can’t emphasize this enough – a single sentence can unlock 80% of the value. Writing something, anything, is so much better than writing nothing, and yet, too often, we see companies skip this part of the incident management process.

    Modern incident management, as a practice, was born on factory floors.  Instead of firing the person who was considered accountable for a major incident, having that person write up their view of what happened was more impactful at preventing future incidents. That’s because only the responder has the complete context to shed light on the contextual, systemic failures that actually caused incidents, as compared to the outside view of management and other employees who will often see problems as human-centered or due to obvious oversights (using 20/20 hindsight).

    When asked if he would fire an employee who made a $600,000 mistake at IBM, Thomas J. Watson famously replied, “No! I just spent $600,000 training him – why would I want somebody to hire his experience?”

    The reality is that any amount of your unique perspective as a responder is invaluable when compared to nothing, and without it, the chances of your company learning from these mistakes is slim. That’s why we encourage a unique approach: we tell our customers to spend four seconds on their postmortem.

    Especially for those new to incident response and management practices, it’s important to develop a practice of doing postmortems right away, as soon as the incident closes. As quickly as possible, open up your postmortem, jump to the ‘What Happened?’ section, and write one useful sentence. That’s it.

    Once you do that, we know that one of two things will happen:

    1) You’ll have other things to do, so you’ll publish the postmortem, and that one critical piece of knowledge will be shared throughout the company. That is infinitely better than nothing. 

    2) Or, you’ll realize you have more to say and get it done, right then and there.

    Like putting your running shoes on even if you don’t want to go for a run — at the very least, you’re up and active; at most, you’ll get out there and rack up some miles.

    Working with companies across industries and seeing thousands of incidents filed; hearing the stories of hundreds of companies’ incident management implementations has taught us that the alternative to a quick postmortem often isn’t often a more in-depth one, it’s no postmortem at all.

    So if you’ve just finished an incident– and if you’re about to pick up your coffee and move on to the next task at hand – instead, spend four seconds writing one sentence. It could make all the difference.

  • Report: The State of DevOps Automation

    Report: The State of DevOps Automation

    In the race to accelerate digital transformation initiatives, organizations are encountering more incidents, more downtime, and longer resolution times. In fact, 90.4% of organizations saw an increase in incidents since the pandemic began, according to a recent Transposit report.

    In a completely digital economy, service downtime takes a higher toll. For ITOps teams, working remotely also requires new strategies to organize a team’s response to issues. Amid rising incidents, 94.1% of organizations have increased their focus on service reliability engineering (SRE) practices.

    Transposit just released their 2021 State of DevOps Automation report, which surveyed over 500 IT, DevOps, and SRE professionals across the U.S. The report sheds light on the state of remote work as it relates to incident response processes, reveals increased demand for SREs and highlights the automation they’re using to narrow the resolution time gap. Below, we’ll explore the report’s key takeaways and discover what sort of DevOps automation is trending.

    Remote Work Slows Incident Response

    Try as they might, videoconferencing and group chat solutions like Zoom and Slack just can’t compete with in-person collaboration. According to the survey, 93.6% of ITOps and software teams reported it takes longer to resolve incidents while working remotely.

    Since the pandemic began, 97% of teams have adopted remote work, and 90.4% have experienced increased service incidents. It doesn’t bode well that incidents are increasing as incident response time lags.

    The report findings frame remote work as a top hurdle to resolving issues — 46.1% reported that not being physically in the same room to collaborate on fixing issues was a top concern. But remote work is only one element; others cite changing processes and a lack of visibility into who’s responsible for maintaining code as another challenge.

    Incident Response Hangups

    To make up for these concerns, organizations are investing in incident response strategies. The report found that 56.4% of companies are adopting communication and collaboration tools, with automation tools at 52.3% and integration tools at 43.9%.

    Though the report showed greater investment in those tools, it also identified a persistent communication gap. When conducting postmortems, it can be challenging to correlate human action to incident responses. More than half (57.4%) of respondents felt it’s hard to piece together human actions and team communication during incidents. This context is essential to make sense of mean-time-to-response (MTTR) metrics.

    Interestingly, the report found 96.4% of respondents believe mining insights from human data, like Slack channels or group emails, could help improve incident responses. It appears that having a clearer way to harvest and query incident-related data throughout the entire response process is a universal concern.

    SRE Goes Mainstream

    As I previously reported, the SRE role continues to evolve and gain favor. The report similarly hypothesizes that, based on the survey results, the SRE title is going mainstream. Out of 295 respondents surveyed, 98% said they increased SRE practices in the last 12 months, and 62.4% said they would be expanding SRE efforts in 2021.

    In 2021, SREs will likely remain a hot commodity in hiring. However, these individuals will face mounting complexity in addressing real-time incidents for complex distributed systems. They will also likely be tasked with automating manual processes, as 51.7% of respondents reported that a lack of automation is the top cause of slow incident resolution.

    Automation Goals and Barriers

    40% of companies surveyed now have at least one dedicated full-time staff member working to create in-house tools or bots to automate incident responses. So, what sort of automation is common in the SRE field? The report shows SREs constructing custom scripts to automate things like:

    • Customer communication
    • Recording MTTR metrics
    • Automating infrastructure
    • Corporate communication
    • Auto-generating runbooks
    • Creating or updating tickets

    But, automating these processes is not all that easy. As a top barrier to automation, DevOps professionals collectively cite a lack of documentation. It seems by replacing tribal knowledge with up-to-date, shared documentation, teams could quickly unlock some gains. So, make documentation accessible, and provide copy-and-paste abilities for sample scripts.

    SRE and Automation to the Rescue

    The study demonstrates how the remote economy has increased both the number of incidents and the mean response times to address them. To fill this gap, organizations increasingly turn to site reliability engineering practices to automate incident responses. By leveling up DevOps with SRE, teams could reduce errors and improve overall availability as development teams progressively deliver new features.

  • Low-Code Makes API Testing More Accessible

    Low-Code Makes API Testing More Accessible

    APIs are rising both in quantity and business value. But with that growth comes an increasing number of vulnerabilities, which could affect cloud service dependencies and internal APIs. Functionality and uptime could also suffer as cloud services evolve their APIs with new versions. Thus, API endpoint testing is critical to ensure a reliable back end. With growing interest across the organization to stabilize these integrations, how do we test APIs in a reproducible way that non-developers can grasp?

    Low-code platforms — tools that enable workflows with visual programming models — are opening doors for citizen developers to construct applications in a visual mode. Similarly, the low-code concept could aid API testing by providing an easier method to create API tests to verify functionality and uptime. This could arm quality assurance, DevOps and site reliability professionals with an easier means to test high-value integrations and their UI representations.

    Amid a growing headless movement, APIs are now powering many end-user experiences. However, during a developer drought, it may be challenging to find talent with integration know-how.

    I recently met with Dan Belcher from Mabl to discuss combining low-code and API testing. Here, we’ll uncover why it’s difficult for non-engineers to conduct API testing and consider what API testing must address to ensure today’s software meets tomorrow’s digital innovation demands.

    A Low-Code Approach to API Testing

    The software landscape has evolved rapidly in recent years. “Many forces have combined to create an incredible amount of change,” said Belcher, citing DevOps, CI/CD, the API economy and agile enterprises as examples. In this era, applications are becoming more dynamic, disrupting the way teams conduct end-to-end quality testing.

    API-based cloud services are part of this new frontier, becoming popular building blocks within modern applications. Yet, integrations require upkeep as cloud services evolve and version. Without continuous testing of API-based cloud services, organizations could easily suffer from breaking change and poor usability.

    Unfortunately, as it stands, typical QA teams aren’t well-equipped to handle ongoing regression testing for APIs. Instead, “developers, historically, have been the only ones that understood API testing,” explained Belcher. For years, API testing has been relegated to the realm of developers, who use tools like Postman to perform unit-level testing. But why is API testing so difficult for others?

    What Makes API Testing Difficult?

    Well, to start, non-engineers are typically more accustomed to UI-based testing. These environments use a structure designed for anyone to consume, making it easy to locate fields and confirm values, Belcher explained. When it comes to API testing, you often must handle massive chunks of JSON responses to match fields and surface issues. Testing API responses typically requires writing code, parsing JSON and writing it to variables, Belcher explained, which may be difficult for non-developers to implement.

    Or, difficulties could arise when testing asynchronous endpoints, Belcher added. Asynchronous APIs often involve background server processes that take a while to respond. This comes at a moment when event-driven architecture (EDA) is a growing trend. Take AsyncAPI, a standard API specification for EDA APIs, which recently joined the Linux Foundation. A recent report found AsyncAPI production usage tripled from 5% in 2019 to 19% in 2020. According to Belcher, testing such asynchronous services requires an infrastructure for continuous testing to anticipate these emerging scenarios.

    Four Crucial Areas For API Testing

    So what should API tests be focusing on? Belcher highlighted four areas that warrant close examination throughout the API testing process:

    • Functionality: This is the core functionality. Does the API do what it promises? Does it return the correct data?
    • Uptime: What is the API’s availability? Are all endpoints available in production?
    • Speed: This ensures cloud dependencies meet SLAs. What is the latency? Is there drift in API performance over time? Though API monitors like Api.expert help aggregate industry performances, they might not always reflect your specific customer-level realities. Belcher recommends not placing faith in supposed performance and instead, clocking your own.
    • End-to-End: Belcher stresses the role APIs now play across customer-facing presences. An end-to-end workflow should involve API endpoints, how they interact with one another, and the resulting visual representations. “Just like we have end-to-end testing for UIs, we should have end-to-end testing for APIs,” he said.

    API testing isn’t always combined with other parts of the user experience, but Belcher believes, going forward, end-to-end testing will be critical to ensure all workflows function in concert. For example, if a user profile is created within a browser, teams should verify the user profile has been created at an API level, as well.

    Low-Code API Testing and Shift Left

    APIs are beneficial to avoid reinventing the wheel. However, 100% operational uptime is impossible. Applications will inevitably encounter API problems, including outages, technical failures and functional misrepresentation. Developers also often come to rely upon production behaviors that may not be officially documented, an effect known as Hyrum’s Law. This can cause unstable integrations as APIs version over time.

    Thus, for these reasons and more, it’s a good practice to adopt continuous API testing. With the surging interest in site reliability engineering, spotting API errors early on will become an important aspect in reducing mean time to recovery (MTTR). Testing third-party APIs could also expose production latencies to inform cloud investments.

    “As the pace of change is going up, how do we deliver great quality to our customers?” Belcher asked. API testing is one answer to address this rapid change, and is growing in importance for the software delivery life cycle. It especially rings true for headless frontend experiences, where the API-driven backend isn’t transparent to QA testers.

    Low-code capabilities for API testing could help tear down silos inherent in the development process, enabling more people to participate in testing integrations. Belcher also stresses the importance of improving the usability of API testing for developers and non-developers alike. “We need to integrate with tools developers are already using for verification,” he added.

  • The Surprising Secret to DevOps ROI

    The Surprising Secret to DevOps ROI

    As a result of my many years of DevOps consulting, I have discovered a simple, but not well-understood, secret ingredient that drives ROI for all the Three Ways of DevOps.

    Measuring and optimizing return on investment (ROI) for DevOps is not well-understood. It is a proven fact that DevOps, when engineered well, delivers tremendous value to organizations by way of continuous delivery practices. Reduced lead time, more frequent releases, lower failure rates and faster time to restore services are well-accepted indicators of DevOps value. It is not a secret that the combination of engineering DevOps practices for people, processes, and technologies around the Three Ways of DevOps – continuous flow, continuous feedback and continuous improvement – gets results. As valuable as these things are, they are not a measure of ROI, and do not tell you what to do to improve the return on your DevOps investments.

    How Do You Calculate and Optimize DevOps ROI?

    First, it is important to understand that ROI for DevOps is best measured using a simple ratio of return (R) divided by investment (I). (OK – for the accounting purists out there; I know the real ROI formula is actually (((R-I)/I)*100%) but that is a technicality that we don’t need for this argument.)

    The “return” of DevOps value is the important factor in the numerator of the ROI ratio. While there are many values that can be attributed to DevOps, the most direct value that can be measured and justified for legitimate comparison purposes is the cost savings associated with accelerating software delivery value streams. Application developers, and others, can get more applications released faster because of DevOps, which has a dramatic effect on valuable cost reductions. The “investment” in DevOps projects is the denominator of the ROI ratio. To optimize ROI, simply increase return by getting more application releases out faster, while reducing the investment required for a DevOps project. Sounds easy enough. But wait! How do you do that?

    The primary factor in the return is derived from reducing bottlenecks. I have found, in more than half of the thousands of DevOps value streams I’ve studied, that the biggest bottleneck is testing! It is a myth that continuous testing is just the execution of automated tests. I am talking about the whole range of ‘testing things,’ including test strategy, test planning, test resource scheduling, test design, test implementation, test environment management, test execution, test results reporting, test result analysis, troubleshooting, fix, retest and test management. That is a lot! In fact, testing things are a source of bottlenecks for every stage of a DevOps pipeline, for all three ways of DevOps. The point is that ROI can be greatly improved by improving testing.

    As it turns out, the primary factor in reducing investment costs also has to do with testing! Putting ‘testing things’ in place is expensive in terms of labor and capital costs for both people and systems. The primary factor to reduce total investment cost is to standardize, share and use ‘testing things’ with as many application pipelines and stages as possible.

    What is the secret ingredient that I have discovered? After all, the importance of testing itself is not much of a secret. I have isolated the key ingredient that is the heart of all ‘testing things.’ The purpose of a test is to determine a verdict. A test verdict is the codified representation of a pass, fail or inconclusive result state of a test, assessed relative to the purpose of the test. Test verdicts are essential, no matter what kind of test it is; no matter the stage in the pipeline a test is used. Without a verdict, all the ‘testing things’ in the world are not valuable.

    So – the secret ingredient for optimizing DevOps ROI is to optimize test verdicts. Those that know how to optimize test verdicts hold the key to optimizing DevOps ROI.

    As I indicated in this eBook I authored for the DevOps Institute, verdicts from properly engineered testing at each stage in the pipeline are essential for assessing the artifacts produced in each stage.

    How Can You Optimize Test Verdicts?

    As I have pointed out in prior articles, well-engineered DevOps requires balancing the nine pillars of DevOps.
    Surprisingly, test verdicts play a crucial role in optimizing all nine pillars of DevOps, and are vital to accomplishing the best return for the least cost investment in DevOps. Here are some examples of how this works for each pillar:

    Leadership – Leaders tend to underestimate the importance that ‘testing things’ have on DevOps ROI, and that the central ingredient of test effectiveness is the optimization of test verdicts. By sponsoring DevOps projects and training programs that drive improved test verdicts, leaders will have a direct and lasting impact on ROI.

    Collaborative Culture – How often have you seen people wasting time arguing over the meaning and importance of a test? Collaboration between application developers and QA and Ops teams is more effective when test verdicts are clear and based on a common understanding of the purpose and importance of each test.

    Design – The creation of excellent tests, designed to efficiently resolve to clear verdicts during the design phase, makes for reusable test assets in all subsequent stages and releases, and can be reused with other applications.

    Continuous Integration – The validation of builds is faster when all integration tests are arranged to get clear verdicts quickly during the build process.

    Continuous Testing – Test verdicts associated with each test are the key information ingredient that test management systems can key off to optimize test selection and test execution for each stage in the continuous delivery pipeline.

    Elastic Infrastructure – Test environment management (TEM) systems can optimize the orchestration of test resources better when test verdicts are clearly understood. Knowing a history of verdicts for a group of tests indicate which resources and how much of each resource are needed to run each test. This knowledge is essential to drive test environment management systems that have scaling algorithms for optimizing the use of ephemeral test environments, and to ensure test resources are used optimally.

    Continuous Monitoring – Reporting and analysis of test results can be a major bottleneck in the pipeline, but can be dramatically accelerated when the test verdicts are clearly defined.

    Continuous Security – Security tests are not much use without a clear verdict. While there is no such thing as 100% security assurance, the aggregate set of security test verdicts helps to profile security for applications and releases.

    Continuous Delivery – Algorithms that govern the ‘doneness’ of an application release candidate, and decisions to promote a release to production, depend on analysis of service level objectives (SLOs) derived from service level indicators (SLIs), including test verdicts. The fidelity and quality of those verdicts is essential for operations and site reliability engineering (SRE) teams to be confident enough to not bottleneck an application release.

    What This Means

    Measuring and optimizing DevOps ROI requires strategies that deliver value by improving returns through reducing bottlenecks and reducing investment costs. ‘Testing things’ are a dominant factor contributing dramatically to both the return and investment components of the ROI equation. A comprehensive strategy for optimizing test verdicts is the secret ingredient for optimizing and leveraging investment in ‘testing things,’ which, in turn, has a dramatic effect on improving DevOps ROI.

  • CircleCI Previews Support for Arm Platforms

    CircleCI Previews Support for Arm Platforms

    CircleCI today previewed the ability to deploy applications on platforms based on Arm processors in a forthcoming release of its namesake continuous integration/continuous delivery (CI/CD) platform.

    Tom Trahan, vice president of business development for CircleCI, said that Arm processors are rapidly being embraced by DevOps teams seeking to take advantage of the price/performance advantages they currently have over conventional x86 processors. Amazon Web Services (AWS), for example, makes available an AWS Graviton2 service based on 64-bit Arm Neoverse processors that it claims provides a 40% advantage in overall price/performance.

    The Arm community, meanwhile, has adopted many of the libraries employed on x86 platforms, Trahan noted, which is making it simpler to automate the deployment of applications on Arm-based platforms using a CI/CD platform.

    It’s not clear how quickly developers are building applications for Arm processors. Historically, Arm processors can be found in a wide range of embedded systems typically deployed at the network edge. However, cloud services based on Arm processors are also becoming more widely available, and it’s only a matter of time before more Arm-based platforms are deployed in on-premises IT environments.

    Arm itself is also in the process of being acquired by Nvidia, which envisions running machine learning algorithms, and other classed of advanced workloads, on both Arm processors and graphics processing units (GPUs). Many of the early efforts to build processors optimized for running AI workloads at the network edge are based on Arm processors.

    The addition of Arm platforms to any IT environment will naturally create some management challenges for DevOps teams. In some cases, developers may even decide to build applications using, for example, the latest generation of machines from Apple, that are based on Arm processors, to streamline the application development and deployment process. In other cases, however, applications that are intended to be deployed on Arm processors might still be built on x86 systems.

    Regardless of approach, the arrival of more Arm-based platforms in the enterprise doesn’t mean other classes of processors are going to fade away. Rather, from a processor perspective, IT environments are about to become a lot more diverse as more workloads are deployed on a wider range of processors. It may be quite a while before Arm-based platforms usurp x86-based systems that still dominate the IT landscape. However, during any turbulent economic time, the number of organizations inclined to reduce the total cost of IT by embracing new platforms always increases.

    Fortunately, as more IT infrastructure is managed as code, the easier it becomes to switch platforms. There may even come a day when the decisions about which platform to employ and when is completely automated by machine learning algorithms trained to maximize IT infrastructure efficiency to the fullest extent possible.

    In the meantime, DevOps teams should expect, to one degree or another, to revisit their workflows processes in the months ahead. Not only are more workloads being pushed out to edge computing platforms where Arm processors are commonly found, those Arm processors will soon find their way into the rest of the extended enterprise.

  • LeanIX Extends Application Management Reach

    LeanIX Extends Application Management Reach

    LeanIX today unveiled a catalog that enables DevOps teams to more easily track the relationships between microservices as they are built and deployed.

    At the same time, the company also revealed it has acquired Cleanshelf, a provider of a platform for managing software-as-a-service (SaaS) applications.

    LeanIX CEO André Christ said the Microservice Intelligence catalog will make it simpler for IT organizations to keep track of their ongoing software development efforts, while Cleanshelf provides the mechanism for centralizing management of SaaS applications that are now widely employed across the enterprise.

    The Microservice Intelligence catalog is the latest addition to the LeanIX Continuous Transformation Platform used to manage enterprise applications. It automatically captures and correlates metadata being generated across disconnected toolchains, pipelines and Kubernetes clusters to create a 360-degree view of microservices and their dependencies, said Christ.

    In addition to being integrated with the LeanIX Enterprise Application Suite, Microservice Intelligence comes with out-of-the-box connectors for Kubernetes, Jenkins, GitHub Actions and Red Hat OpenShift platforms.

    By monitoring deployment frequencies, mean-time-to-recovery (MTTR) and failure rates, Christ noted it will become easier to make software engineering decisions based on data and insights surfaced via the Microservice Intelligence catalog. DevOps teams can also annotate the microservices recorded by the catalog to provide additional information, Christ added.

    The Microservice Intelligence catalog provides the added benefit of making it easier to onboard new developers, said Christ. Each new member of a development team can, on their own, explore the overall application environment without requiring an IT team to dedicate someone to describe it each time a new member of a DevOps team is hired, Christ noted.

    At the same time, other stakeholders, such as cybersecurity teams, can explore the application environment to better understand dependencies as well as the potential impact of a newly discovered vulnerability, Christ added.

    In general, Christ said, as application life cycle management across the extended enterprise becomes more complex it’s clear new platforms will be required to manage legacy monolithic applications, emerging microservices-based applications and SaaS applications that, in the wake of the COVID-19 pandemic, are being used to enable employees to work from home. The Cleanshelf platform, in particular, will be rebranded as LeanIX SaaS Intelligence to address that latter issue. A SaaS discovery and cataloging capability will also be made available as a free component of the LeanIX Application Portfolio Management module in the second quarter.

    IT environments have never been more distributed, and it’s clear most organizations are under pressure to reduce the total cost of IT by centralizing management functions. It’s too costly to dedicate a management platform for each type of application deployed across an extended enterprise. LeanIX is making a case for a platform that enables IT organizations to finally centralize the management of application environments.

    It’s unclear at what rate that centralization may occur, given the level of inertia that exists within most IT organizations today. However, as application lifecycle management continues to evolve, the centralization of the management of application portfolios that continue to grow is all but inevitable.

  • On-Premises Software Delivery Tool: Build or Buy?

    On-Premises Software Delivery Tool: Build or Buy?

    The on-premises software market is four times larger than the SaaS market, but harder to reach. Every software vendor who wants to pursue it has to decide how they are going to package and deliver applications inside customers’ firewalls, automating away the complexity of keeping applications deployed and running. Should they build or buy a deployment tool (and how should they think about the features they’ll need beyond just deployment)? Both have their pros and cons, but as demand to reach the larger enterprise market grows, more software vendors are choosing to buy.

    Deploying apps on-premises used to be very different. Fifteen years ago, sysadmins and database administrators (DBAs) would manually configure servers and the applications that ran on them. When something broke in production, admins would often troubleshoot and fix by SSHing in to tweak a config file or setting. But now, particularly within agile development organizations, everything is done via automation (i.e., the evolution of DevOps and SRE). As a result, customers have lost patience with 150-page installation manuals and bespoke, hand-written scripts.

    Today, any ISV looking to modernize an existing on-premises app (or SaaS-only company considering creating their first on-premises offering) is, most likely, going to default to using Kubernetes because it abstracts away the technical overhead of keeping production-grade applications operating.

    With that in mind, software vendors should consider seven areas when deciding whether to build or buy a delivery and management solution. These include:

    Maintenance

    There are free or low cost resources if a software vendor wants to go it alone. Kubernetes and cloud-native technologies let capable engineers stand up a solution in months. But software vendors often overlook the long-term cost of keeping the tool up and running. There is a lot of tooling “around Kubernetes” the vendor has to build to successfully operationalize this. Sure, if you’re going to deploy to up to five customers, you don’t need formal tooling and processes that make it easy to engage whole teams of people (favoring a small build and manual effort), but when you want to go from five to 50, or 50 to 500 customers, you need advanced tooling (favoring buy).

    Cost

    Purchasing a ready-made solution comes with up-front costs, but building and maintaining a bespoke solution can be much more expensive. The obvious costs of building a deployment tool are design, engineering, support and operational costs. There are larger, long-term costs to consider, most notably pulling away one of your greatest assets, software engineers, to spend months (or years) on ongoing support needs. Redeploying your engineers results in opportunity and productivity costs, such as neglecting your core application(s) and stalling your business growth.

    Internal Resources

    You also need to evaluate your internal resources. Building a bespoke deployment tool is a commitment because the tool becomes a product in and of itself. Do you have a team with the available time and the technical skills? If your team isn’t large enough, you may incur costs for expanded headcount or contractors. If you don’t have added FTE costs, you may have a skills gap. When developing a custom deployment tool, most teams focus on the features that enable software distribution and installation, but they don’t consider management and troubleshooting features. In these situations, the FTE and skillset costs may be higher than paying for a comprehensive solution.

    Business Continuity

    Most homegrown solutions are created by an engineer or two who become experts in the systems they’re developing. This makes tons of sense for core business logic, apps that are constantly going to be improved and onto which new members will be onboarded. However, for ancillary systems that support the core business, these applications end up becoming a silo of knowledge. The question isn’t, “How much time will this take me to maintain after I build it?” but rather, “Who will maintain this after me, and who after them?” followed by, “How will they learn the intricacies of this system?” If the answer(s) to this question isn’t clear, this approach should be reconsidered.

    Beyond The First Team

    If you expect that your team will be the first, or one of the first, teams within your company to face the problem you are solving for (but you are certain others are sure to follow), then this decision is even more complex. A common customer delivery and management platform can increase cross-sell by simplifying the marginal effort for your customers to deploy a second, third, fourth, etc. application from your company. Buying will likely require a long-term relationship with a vendor dedicated to solving the problem. Similarly, building a solution will require extra investments. Beyond the initial technical/product requirements of abstracting a home grown solution to meet the needs of additional teams/architectures/products, there are also the other implications. The winning solution will win because it will evolve to meet the needs of multiple teams and have strong internal advocacy. Depending on the size and complexity of the company, this internal advocacy can be quite time consuming and require more than just engineering talents (generally, this is what customer success and account managers do 100% of the time).

    Target Environments

    Your application may need to be deployed in varied on-premises environments and may not have the time to adequately address all of them. If your team has not previously built an installer, they may not have the skillset to build out richer features in AWS, Azure, VMware and others, to solidify the customer experience and day 2 operations, beyond just bringing the application up. An AWS Cloud Formation template might get you out the door, but when the next customer says, “I need GCP,” you’d have to start over.

    It’s rinse-and-repeat for each of the target environments, which slows your time-to-market, potentially losing high-value sales. Conversely, if you look at ready-made solutions, you can select the best out-of-the-box experience for your customers.

    Control and Compatibility

    There are situations where your team must build the on-premises deployment tool themselves. For example, when the app requires so much last-mile configuration for each customer deployment that there just isn’t a way to standardize it. Or if you don’t have enough customers to justify paying for a commercial product, it might make more sense to do a quick sprint and hack something out.

    An off-the-shelf solution can significantly accelerate your time to market, but you have to order off the menu. Also, if you have access to your customer’s infrastructure, then building your own tool may make more sense. On the other hand, requirements such as faster time-to-market, an off-the-shelf comprehensive solution and lower costs over time may outweigh customization. If speed, lower costs and quality are important, a solution from a focused vendor who has thought through all of the technical and operational challenges, with no surprises or last-minute fixes, is the way to go.

    Competitive Advantage

    Your software engineering team may be your company’s greatest resource. But it’s far better to keep your engineers focused on innovation, adding value to your application and winning more customers through improved software. Coding a deployment tool is undifferentiated overhead. It does not make your business more successful. Installers and support tooling are table stakes to deliver a good customer experience, but the reality is that no customer is going to pay you more money for that capability.

    The Bottom Line

    Simplified access to the on-premises software market is one of the greatest opportunities for software vendors today. Kubernetes and cloud-native technologies make it easier to develop tools to package, deploy, manage and troubleshoot apps. But the job isn’t for everyone. The costs, both up-front and long-term, favor ready-made commercial applications for most software vendors. Consider your resources and customer needs to decide if it makes more sense to build or buy your solution.

  • Harness Revamps User Interface for CI Platform

    Harness Revamps User Interface for CI Platform

    Harness today announced it has updated the community edition of its continuous integration (CI) platform with, among other updates, a revamped user interface.

    Formerly known as Drone.io, the latest release also adds pipeline execution visualizations, governance and security controls and live CI pipeline debugging capabilities. Harness last year acquired Drone.io, an open source CI project, to extend its existing continuous delivery (CD) platform into the realm of CI. Harness claims there are now more than 50,000 active monthly users of the community edition of Harness CI.

    Brad Rydzewski, co-founder of Drone.io, said the user interface for Harness CI will soon be applied across the entire portfolio.

    The update to the community edition of Harness CI comes at a time when the debate over how tightly integrated CI and CD platforms need to be is heating up. Harness launched a namesake CD platform before it acquired Drone.io to add a CI capability. While most DevOps teams are proficient with CI, the CD side of the DevOps equation has proven more elusive. There are now GitOps advocates that contend the rise of Kubernetes makes it more advantageous to enable a separate CD platform to pull updates from a Git repository, rather than having them pushed out by a CI/CD platform. The challenge with CD has always been that each platform on which code is deployed is unique. Kubernetes, however, now provides a de facto standard layer of abstraction that runs atop multiple platforms.

    Rydzewski said the integrated CI/CD approach will ultimately prevail, because it enables DevOps teams to more easily integrate a range of processes, including testing, that are required to consistently build and deploy applications at scale. Harness is, essentially, making a case for solving the CD challenge using a platform that encourages – but doesn’t require – a DevOps team to replace their existing CI platform.

    Regardless of how DevOps evolves, the CD issue needs to be addressed. As the enterprise becomes more extended with the rise of both cloud and edge computing, the number of platforms a DevOps team needs to support continuously expands.

    Despite the fact that DevOps teams employ CI/CD platforms, it is clear most of those organizations are not overly committed to the way they currently manage CD. It may be years before most organizations finally implement a consistent set of processes for automating application deployment.

    In the meantime, the number of organizations just starting out on their DevOps journey continues to increase. There are still plenty of instances where organizations have yet to deploy any type of CI/CD platform. It’s also worth noting that, in many cases, different DevOps teams within the same enterprise have decided to deploy different CI/CD platforms.

    Regardless of how DevOps evolves the pressure to automate is rising. The challenge many DevOps teams face today is the current platform they are relying on to automate the building and deployment of applications requires a small army of specialists relying on all too often manual processes to maintain.