devopsy.kinsta.cloud

Category: DevOps Practice

  • No-Code/Low-Code: Empowering Collaboration

    No-Code/Low-Code: Empowering Collaboration

    No-code/low-code will create seamless integration between cloud platforms, tools and utilities

    Recent developments have created a massive shift to working remotely, which, according to a recent Gartner survey, is not a temporary move. The survey indicates that 74% of CFOs plan to continue some form of permanent remote working. This in turn paves the way to even greater adoption of cloud-based applications and software to enable businesses to stay connected, collaborative and productive.

    While the ongoing pandemic has helped to underscore the importance of cloud-based applications, it has also revealed that these systems don’t always work well together—an oddity, considering the promises of seamless collaboration, transparency and productivity of cloud platforms. But the reality is that while many cloud solutions claim to be “platforms,” they are not. There are, in fact, only a handful of platform companies, including Salesforce, Adobe, SAP and Microsoft. The rest are tools and utilities that should snap into a larger ecosystem.

    Many organizations think they can implement disparate cloud tools and seamlessly switch them on like a light bulb. But that’s just not the case. This is why no-code/low-code will both end the “cloud platform masquerade” and create seamless integration between cloud platforms, tools and utilities.

    The Rise of No-Code/Low-Code

    No-code solutions typically allow non-technical developers, such as business users, to build or modify apps without having to know any programming languages. Low-code applications, for their part, are enterprise-grade systems built by professional developers that offer drag-and-drop components and require little or no hand-coding.

    The beauty of no-code/low-code applications is that they do not require an army of expensive IT consultants and systems integrators to get them to speak to each other. Instead, these applications are designed to plug seamlessly into an integration platform as a service (iPaaS), a suite of cloud services that connects various applications, systems and technologies within the cloud. As a result, no-code/low-code cloud apps can easily communicate and share data even when they don’t speak the same language.

    Think of it as Google Translate for cloud software. With iPaaS, you can stitch together disparate systems that don’t even know they’re communicating to work together in one smoothly functioning, integrated process.

    The Benefits of No-Code/Low-Code

    The benefits are clear. Instead of handing over piles of cash to systems integrators, organizations can reinvest that money in their own companies. What’s more, they can gain greater visibility into their data, enabling them to correlate information and create contextual insights around many aspects of their business. Individual departments can interact with and combine various applications on their own, without the aid of IT, to quickly and seamlessly model new business processes. That in itself is transformational because it puts the power back in the hands of the non-technical professionals, who know better than anyone what they need to accomplish.

    Going forward, I believe organizations should demand cloud-based tools and systems that offer a no-code/low-code component. After all, systems that don’t seamlessly integrate with each other pose a clear impediment to success. For instance, something as simple as a sales lead can have 10 different meanings in 10 different Martech systems. In one, a sales lead may be a click, while in another, it may be a personal contact. This kind of confusion can be deadly to your marketing efforts.

    Moving Forward

    Greater visibility and orchestration will be more critical than ever in our post-pandemic world. As organizations are figuring out how to respond to the rapid upheaval caused by COVID-19, embracing no-code/low-code applications presents a vital path for improved collaboration, transparency, efficiency, productivity and decision-making—all critical requirements if organizations are to overcome this period of crisis and succeed in the future.

  • A Daily Gemba Walk for a Software Delivery Organization?

    A Daily Gemba Walk for a Software Delivery Organization?

    Lean thinking has had a substantial influence on helping enterprises to improve the flow of value across their software delivery organization. Yet, for many companies in what industry visionary Brian Solis calls the “Novel Economy,” where market conditions have yet to be identified or understood, the degree of responsiveness and agility required to adapt and remain competitive is still not sufficient.

    By measuring how value flows through a product’s value stream, however, everyone from practitioners to business leaders can initiate “daily Gemba walks” to obtain real-time continuous insight into the software delivery value streams that serve internal and external customers. You can see what’s slowing you down today and where to invest resources to continuously improve where it matters to support both the customer and employee experience.

    Unique Challenges in Software Delivery Value Streams

    A software delivery value stream is the sequence of activities an organization undertakes to respond to a customer need that results in the delivery of value. Yet, they are not so easy to identify and measure because much of the work is knowledge-sharing. While Lean practices such as value stream mapping have helped us to identify the current state of processes, learn to see where bottlenecks are and learn to improve with experiments to reach a desired future state, there are significant challenges.

    Logistics such as scheduling time, people and the right kind of meeting room, as well as extracting objective data for improvement strategies, make it difficult to keep a regular cadence of assessing the value stream. And, within a relatively short amount of time, the information we captured goes stale, because priorities and strategic initiatives are dynamic and ever-changing.

    Furthermore, since the software delivery work from ideation to operation is mostly cognitive and often complex, it is difficult to accurately map the flow of value. The process flow is not linear—it’s more like a network. The complexities of the interrelated components and variability of how teams work are difficult to capture in an understandable manner. As a result, we lack complete and objective visibility into the end-to-end flow of work to make time-critical decisions to improve performance.

    Going to the Gemba

    There’s a concept in Lean thinking of learning by going to the place where the actual work happens—“the Gemba”—to observe the work first hand. However, in software delivery at scale, even if we take a Gemba walk through the floors of our buildings where members of the value stream are working, we won’t gain much understanding of what’s going on. We might see kanban boards, huddles and charts, but what we mostly see are people working on their laptops at their multi-screened-in desks. We only really see a small slice of the set of activities that create value.

    So how do we see all the activities across the whole value stream at a continuous cadence to help us make both reactive and proactive decisions to improve flow in the most pressing areas? One approach is Flow Metrics, as described in Mik Kersten’s book, “Project to Product,” via the Flow Framework.

    A lean and prescriptive approach that guides organizations on what and how to measure in software delivery at scale, the framework uses Flow Metrics to provide business and IT leaders with shared, real-time insights into the relationship between technology delivery and business outcomes. It helps you to establish your baseline to see where you are today and pinpoint where you need to focus your energy.

    These value stream metrics track the flow of business value by correlating the investment in accelerating flow for each product’s value stream with the desired business outcome. We can use these metrics to scale what we used to do in our value stream mapping sessions to a daily Gemba walk based on objective data without interrupting the teams involved.

    We can see first hand the velocity at which our teams are producing value. We see the efficiency and distribution of their work. We see the work-in-progress (WIP) and the lead time for value creation. We see the correlation between the product value stream contributors’ hard work and the resulting business results (such as a new feature for revenue; fixed defects for product quality/customer; paying down tech debt to improve delivery speed, security and risk work to protect against breaches, and so on).

    Business-level Metrics That Count

    The Flow Metrics are:

    • Flow Velocity gauges whether value delivery is accelerating. It is the number of flow items of each type completed over a particular period (also known as throughput).
    • Flow Time can identify when the time to value is getting longer. It measures the time it takes for flow items to go from work start to work complete, including both active and wait times.
    • Flow Efficiency can identify when waste is increasing or decreasing in your processes. It is the ratio of active time versus wait time out of the total Flow time.
    • Flow Load monitors over- and underutilization of value streams, which can lead to reduced productivity. It measures the number of flow items currently in progress (active or waiting) within a value stream.

    Alongside the above set of Flow Metrics, the measurement of Flow Distribution helps prioritize specific types of work during specific time frames to meet the desired business outcome. Flow Distribution measures the ratio of the four flow items (feature, defects, debt and risk) completed over a window of time.

    Flow Metrics ideally should be displayed in a single dashboard, providing IT and business leaders with a complete view of value delivery and an understanding of how the metrics are affecting each other. Here’s an example:

    Flow Metrics are opening a real-time window to see the value stream activity that we previously could not see as frequently and as objectively. Consider taking a daily Gemba walk for software delivery to ensure you’re meeting the most pressing needs of your customers, internal and external, to navigate through the opaqueness of the Novel Economy.

  • Documenting: Don’t Build Your Replacement’s Nightmare

    Documenting: Don’t Build Your Replacement’s Nightmare

    Want to reduce headaches tomorrow? Document everything today

    About once a year I feel the need to remind you that you are creating technical debt. DevOps is good stuff, and most shops got over the “whatever a given project team decides” multiplication of services pretty quickly, but every line of DevOps code you write is creating technical debt.

    There is no way around this fact. You are writing code (scripts, if you prefer) and developing configs that make assumptions. Those assumptions will change—products will get incompatible upgrades, vendors will go under, libraries will become outdated … the list goes on.

    We have a long history with technical debt. DevOps partially grew out of the need to spend less time maintaining and more time releasing features, and yet we’re re-creating technical debt; in some cases at a much larger scale. It is unavoidable but can be managed. Keep a reference list of assumptions—“This app assumes environment contains X,” or “This app supports Cisco Network APIs version X.Y”—so you know where to look when things inevitably go wrong. The list conveniently doubles as a handy reference to what needs updating when you find out your middleware vendor is going under or that MySQL is out and MariaDB is in.

    The more cutting-edge tools you use, the more likely that you are baking future problems into your environment. This is not advice to avoid cutting-edge; it is advice to recognize reality and keep closer track as you move new things into your environment that might be half-baked or whose market is destined for consolidation.

    Our IT environment has become super-complex. DevOps helps us manage that complexity but discourages adequate documentation. We’ve all heard, “It’s self-documenting” (no, it’s not) or “There is basic documentation” (basic almost always means, “We scratched some notes when it was first set up”… and haven’t touched them since). Don’t do that. Make sure that the new guy after all of you have left can figure out what is going on in this highly complex environment. It is not up to new people to be super-learners with mind-reading skills; it is up to implementors to make certain new people can figure out what is going on without wasting 5,000 hours pawing through scripts.

    It does not take much time to document dependencies. It doesn’t take much more to document relationships. Future you will be grateful when they walk in and need to come up to speed in a short amount of time. Because it doesn’t matter how automated it is when the automation breaks—it matters how quickly staff on hand can fix it and get things going smoothly again.

    You’re keeping the world running. Take a second and make sure the next person can, too. And keep rocking it.

  • Vercel Makes Front End Applications Faster

    Vercel Makes Front End Applications Faster

    Vercel this week extended its effort to redefine how front-end applications are developed to reduce dependencies on backend systems.

    The company has created Next.js, which makes it possible to build web applications using a framework based on the React library for creating user interfaces that enable both static generation (SSG) and server-side rendering (SSR). The latest version a Vercel Edge platform based on Next.js has been re-architected to provide faster routing and better caching.

    Vercel CEO Guillermo Rauch said that capability results in a 10x performance improvement that, among other things, enables applications that employ the React framework for user interfaces to automatically pre-render, code-split and hot-reload, with no configuration required.

    Fresh off raising $21 million in funding, Vercel is committed to making it easier to build highly interactive applications that run in real-time by leveraging Next.js, Rauch said. Vercel claims there are more than 30,000 sites running Next.js in production at organizations such as Airbnb, Hulu, Nike, Ticketmaster and Uber.

    Rauch said most developers are looking to take advantage of frameworks that enable them to treat the underlying IT infrastructure as if it were serverless whenever possible using a familiar JavaScript-type tool.

    At the same time, Vercel is making it possible to run Next.js on a local host, which enables integration with React Refresh from Facebook to enable real-time page change visualization on local hosts. New pages can also be pushed automatically whenever data changes. In addition, developers can replicate all the customized functions from a cloud on a local host.

    Finally, the distributed caching provided via Vercel’s content delivery network (CDN) eliminates the need to rely on legacy CDNs that often require repetitive round trips, he said.

    As frameworks such as Next.js are embraced, DevOps teams will need to adjust to applications capable of providing richer application experiences without relying as much on backend infrastructure. That shift has implications for everything from the amount of network bandwidth consumed to the performance of web applications. Rather than continually focusing on backend infrastructure to optimize application performance, Rauch said the Vercel platform employs caching, routing and a React framework to optimize application performance.

    It’s not clear whether or how much DevOps teams will nudge developers toward frameworks such as Next.js to develop web applications. In theory, the more efficient web applications are the less time and effort that will be needed to monitor applications. In addition, the overall size of the backend IT environment might not need to be as large.

    One way or another, however, the way web applications are developed is evolving. That doesn’t mean JavaScript-based frameworks will eliminate the need for programming languages such as Java. However, the preponderance of applications relying on Java to invoke backend services soon might be reduced substantially.

  • APIs: The Secret Sauce for Low-Code Platforms?

    APIs: The Secret Sauce for Low-Code Platforms?

    As companies become increasingly talent-strapped, APIs are helping spur a low-code movement to help them remain competitive

    Low-code platforms have the potential to alter how software is built and delivered. By focusing on visual flows and drag-and-drop UIs, low-code platforms dramatically lower the barrier to software development.

    Yet, anyone with a toe in the no-code waters will tell you the space is full of half-promises. Can you scale an entire enterprise software architecture with zero code? Probably not. Can a low-code platform single-handedly create and expose compelling infrastructure? Maybe.

    I recently met with Jon Scolamiero, manager, architecture and governance at Mendix, a Siemens business that bills itself as a low-code alternative, to get to the bottom of the low-code phenomenon.

    Read on to discover why low-code platforms could be the next big thing. We’ll cover low-code benefits and caveats, the use of low-code in agile application delivery and how an API-first emphasis sets some low-code providers apart.

    What is Low-Code?

    Low-code platforms use drag-and-drop tools to help non-developers assemble software solutions. Instead of coding every line, integrating with databases and programming network integrations, low-code users visually construct application models with default containers that initiate the logical processes and data storage abilities they require.

    In this way, low-code is dramatically abstracted from standard software development. Examples of low-code platforms on the market include Siemen’s Mendix, Amazon’s Honeycode, Google’s AppSheet, Microsoft’s Power App and OutSystems. Among these solutions, default configurations and customization abilities vary.

    Low-Code Benefits

    With the growing need for more applications, companies turn to productivity solutions such as low-code development to quicken velocity. There are, theoretically, many other benefits to low-code or “no-code” platforms:

    • Welcomes “citizen developers” into the fold: Low-code platforms offer unprecedented usability for the less technical folks. By reducing the barrier to entry, laypeople can participate in complex application development.
    • Break silos and improve collaboration: Since non-technical roles can become more involved, low-code enables better collaboration between teams. It provides a common language for organizations.
    • Improved time to value: Some low-code platforms allow you to build, deploy and run instantly, thus dramatically reducing development time. Especially if integrated with CI/CD capabilities, using low-code platforms means a greatly decreased time-to-value.
    • Addresses the talent gap: In a world of high engineering demand but few developers, low-code development spurs continual growth in light of a limited workforce.
    • Cloud-agnostic: Low-code can grant cloud-agnostic capabilities, enabling companies to run applications on SAP cloud, Azure or “lift and shift” to other cloud vendors.
    • Platform-agnostic: Low-code platforms also offer device-agnostic capabilities, meaning the application could run native mobile code. A low-code layer could also help cater to other experiences, such as voice, chatbot or smart televisions.

    Low-code could also support digital transformation initiatives for internal, non-commercial solutions. For example, a manufacturer could leverage low-code capabilities to quickly spin up connected digital solutions to help operationalize factory production.

    Low-Code Caveats

    Though low-code suggests many positive outcomes, Scolamiero said that industrywide, there are some issues:

    • Security: Good security with low-code is possible yet complex to implement. Low-code platforms must carefully handle access management and delegate identity throughout the app ecosystem.
    • Normalizing expectations: Low-code isn’t magic. These platforms have their limits and do take time to onboard. Scolamiero encouraged having a robust training program ready and available “to teach everyone how to fish.”
    • Consulting services: Scolamiero cautioned IT leaders to beware of some solutions that taut the low-code or no-code label, yet are more akin to consulting divisions. Buying armies of service people is “not a respectful business model for a customer,” he said.
    • No universal standards: Scolamiero noted that the low-code industry has yet to unite on a data integration at scale method.

    APIs Under the Hood: The Secret Sauce

    In 2002, Amazon CEO Jeff Bezos issued a companywide mandate, which has become known informally as the “API Manifesto.” In it, he stated that “all teams will henceforth expose their data and functionality through service interfaces.”

    This API-first strategy increased internal efficiency and reusability, and eventually enabled Amazon to resell its own infrastructure, creating a whole new class of impressive revenue streams. Lyft is another excellent example of a microservices-driven product.

    Many developers now fully understand the power of wrapping everything in a web service. Yet, based on his conversations with clients, Scolamiero estimated that 1 in 6 CIOs are still unaware.

    “If they were, we would have 10 Amazons at this point, not one,” he said. “It’s really easy to wrap your head around data having value, but now it’s the infrastructure that matters.”

    An added emphasis on APIs fits into the current trend toward event-driven, message-based systems. Having the ability to expose APIs to different clouds increases API elasticity, he said.

    Keeping APIs and Low-Code Under the Hood

    Low-code and no-code solutions promise that anyone can become a developer. While the reality is a bit more complicated, with the right frameworks in place, perhaps teams can become closer to that ideal.

    Utilizing an API-first approach both for systems that comprise low-code platforms and providing the ability to expose data through APIs could give low-code platforms an edge.

    According to Scolamiero, tech leaders are still “digitalizing traditional paper processes.” They don’t often think of streamlining event-driven architecture, or how infrastructure itself could have external value.

    Regardless, if it successfully executes a business case, then it works. Perhaps business leaders don’t necessarily have to know what’s under the hood. That’s sort of the point of low-code, isn’t it?

  • Balancing UX and Privacy With IoT

    Balancing UX and Privacy With IoT

    As more IoT devices track data to improve customer UX, privacy concerns are becoming more prevalent. How can developers strike a balance?

    The internet of things, or IoT, is a system that has changed the way we perceive technology. While it has made the usage of technology easier than ever, it does come with its own set of problems. Being such an interconnected network, IoT’s main threat is its ability to pose myriad security and privacy problems.

    In this article, we seek to discuss how and why privacy is becoming a rising challenge in the world of IoT. By understanding how our privacy and security will be affected, we can take the right measures to reduce our vulnerability to these threats and secure our lives.

    How Interconnected Are Devices?

    IoT devices come with several technical capabilities, most of which have been researched and optimized only to the extent of their functionality. Today, IoT connectivity is available in a growing number of devices and equipment. Smartphones can connect to the internet and several household appliances, which also allows people to control these items remotely. Transportation departments have begun to hash out more advanced vehicle-to-vehicle communication, focusing on improving driver and passenger safety on the road. SmartGrid interconnected technologies allow electricity providers, managers and users to monitor and control electricity use in homes, offices and places of business. Today, several people are also making rampant use of SmartHome technologies to control appliances and home security systems and use fitness trackers to control their movement as monitor their eating and sleeping habits. These trackers are connected to their smartphones for better data aggregation.

    All of these connected devices pose a question: With so much data collection and data tracking being carried out by these devices, aren’t we compromising on our privacy and security?

    How IoT Affects Privacy

    When we consider the compromised privacy of individuals, we are talking about each individual’s loss of control over personal information. When people invest in these interconnected devices, they are not entirely aware of how much of their personal information is tracked and saved by the manufacturer in a bid to improve user experience.

    An individual can lose control if someone hacks into their smartphone or computer and remotely operates other devices. There’s no doubt that our smartphones carry a majority of our information. They are linked to our bank accounts, email accounts and even systems that need authorization. In fact, experts predict that there would be about 31 billion connected IoT devices by the year 2021. Usually, hackers employ methods that are undetected, so more connections would mean an increase in hacking activities as well.

    The data collected from an individual’s smartphone or laptop can give hackers a detailed look into their activities, including internet searches and purchasing power. The information is typically used to work on user experience, but also can be used to target particular products to the individual. Sometimes, this data is even sold to other organizations that are looking for a target audience to sell their products.

    Rising Challenge of Protecting Data

    Data is constantly being stored, transmitted and processed by different companies with the help of IoT devices. With more entry points to access data in the form of smart TVs, speakers, lighting systems, printers and more, your data is more vulnerable than ever.

    IoT vendors, therefore, should have dedicated compliance and privacy rules that alter and anonymize personal data before it is stored. The aim is to prevent the data from being able to identify an individual. Cached data and data that is no longer needed should be disposed of in a secure and organized manner.

    Stored data also must meet compliance with legal and regulatory mandates. This must extend to mobile devices, web presence, cloud applications and any other means by which the data from IoT devices are accessed and managed.

    Affordability of Protecting Data

    Yet another concern among IoT developers is the ability to provide enough security for their services. Limited budgets and manpower constraints can prove difficult for establishments to heed to privacy and security concerns. The reason so many loopholes exist is due to the fact that so many manufacturers focus solely on getting the app out into the market to attract funding without considering the damage that could follow.

    With more and more people concerned with their data privacy, organizations must implement more security checks to avoid ruining their brand authority and trustworthiness due to a data breach.

    Conclusion

    Users today are more connected than ever, which means privacy and security concerns must be top of mind for developers. Manufacturers may argue that data collection is essential to the development of their products and the IoT market in the long run, but there must be more focus on the security of the data and personal privacy concerns. Data collection should be done in a monitored manner, with compliance to regulations from the onset. A recent survey noted that 92% of global consumers want more control over how their information is collected. The same number of people also want to enforce punishments for corporates that violate their privacy. IoT developers, therefore, must strive to find a happy medium that balances security and privacy with user experience.

  • Apollo GraphQL Brings Caching to Client Software

    Apollo GraphQL Brings Caching to Client Software

    Apollo GraphQL this week updated its namesake GraphQL client software that among other things improves performance using in-memory caching application programming interfaces (APIs).

    GraphQL has emerged as a popular alternative to REST APIs because it provides developers with a query engine that provides more control over what data is requested. Similar in concept to SQL, developers GraphQL also makes it possible for developers to describe the data they are exposing via an API.

    Finally, GraphQL APIs are organized in terms of types and fields rather than endpoints. That allows developers to organize APIs within a graph that makes them available via a single request rather than requiring every communication between APIs to occur on a point-to-point basis.

    Apollo GraphQL has created client software that allows developers to employ GraphQL to both query external data in addition to making use of a graph to catalog the services made available within the front end of an application.

    Version 3.0 of Apollo GraphQL client software addresses a caching limitation that stems from the fact generic HTTP caching doesn’t work with GraphQL. Every time an HTTP request is made for slightly different data the cached value is invalidated. When the Apollo GraphQL client fetches data from your server it caches that data using a normalized structure that matches the Apollo GraphQL schema, which allows it to locally reconstruct a subset of the back-end data graph. The next time Apollo Client queries any of that same data it can fetch it directly from the cache.

    Developers can now also define a field policy for any GraphQL field that appears in your cache. A field policy can include a read function that customizes what occurs when the field is read from the cache and a merge function that customizes what occurs when it’s written.

    Apollo Graph CTO Matt DeBergalis said by defining all of this custom field logic in one place developers can avoid repeating code. Other developers can also interact with the types and fields without needing to understand how they’re stored or fetched, he said.

    Version 3.0 of the Apollo client library also now includes support for a reactive variable value that registers a dependency when read.

    Originally developed by Facebook, GraphQL is gaining a lot of traction on backend systems because it allows developers to describe the data that can be accessed. However, because it also makes it more efficient to query data it’s also now being more widely deployed on clients as well. It’s not clear to what degree REST APIs might be replaced by GraphQL, but at the very least reliance on REST APIs in new application development projects is likely to decline significantly.

    The implications of that transition for DevOps teams are significant because the overall performance of applications that rely on GraphQL versus REST APIs should substantially improve. In fact, the biggest inhibitor to GraphQL adoption at this juncture may be simple inertia. Too many developers simply build REST APIs as a matter of reflex without necessarily investigating alternatives. However, it should not be too long before everyone on the DevOps teams starts to appreciate just how much the end user experience really is when GraphQL is employed.

  • OverOps Partners With GitLab to Analyze Code Earlier

    OverOps Partners With GitLab to Analyze Code Earlier

    OverOps has allied with GitLab to integrate a tool that analyzes code at runtime to identify issues with a continuous integration/continuous delivery (CI/CD) platform.

    Eric Mizell, vice president of solution engineering for OverOps, said the plugin for the GitLab CI/CD will make it easier to surface issues with code earlier in the DevOps pipeline. OverOps’ quality gates help determine if code is safe to promote and automatically blocks unstable releases from moving forward to production.

    OverOps combines static and dynamic analysis of code as it executes by relying on machine learning algorithms to collect data. That analysis can be accessed either via dashboards based on open source project Grafana software or shared with other tools via an open application programming interface (API). It analyzes code at runtime to identify all new, increasing, resurfaced and critical errors in a release. OverOps then generates a code quality report that ranks issues in terms of potential to impact end users and application functionality.

    According to a recent survey of more than 600 software development and delivery professionals conducted by OverOps, more than 50% of respondents spend a day or more per week troubleshooting code-related issues.

    The survey also finds that nearly 25% of organizations experience critical/customer-impacting production issues on a daily or weekly basis.

    The earlier code issues are detected the less expensive they are to fix. OverOps is making the case for making its tool part of the quality assurance gate within any CI/CD pipeline.

    The paradox many organizations find themselves in is that as DevOps processes enable them to build and deploy applications they wind up spending a lot more time debugging those applications.

    Eventually, developers wind up spending more time fixing existing application code than developing new applications. Tools such as OverOps are employing machine learning algorithms to reduce the amount of time spent discovering code issues, which should free up more time to write new code.

    OverOps captures machine data about every error and exception at the moment it occurs, including details such as the value of all variables across the execution stack, the frequency and failure rate of each error, the classification of new and reintroduced errors and the associated release numbers for each event.

    DevOps teams historically rely on log data to manually search for anomalies indicative of issues with code. Not only is OverOps faster, but the algorithms will also surface uncaught and swallowed exceptions that would otherwise be unavailable in log files.

    There are a lot of aspects of DevOps that now can be better handled by machines than humans. That doesn’t mean humans will be replaced anytime soon. However, the bulk of time-consuming and monotonous DevOps tasks that exist today are eventually going to be performed by a machine faster and with greater precision. The challenge and opportunity now are identifying the tasks where machine learning algorithms can have the most impact sooner than later.

  • DevOps Was Supposed to Kill Developer Jobs. Here’s Why it Didn’t

    DevOps Was Supposed to Kill Developer Jobs. Here’s Why it Didn’t

    The rise of DevOps is more an evolution than a revolution, and developer jobs aren’t going anywhere

    Development died a long time ago and was replaced by DevOps. Or, at least that was the way it was supposed to happen.

    In reality, developers are doing just fine. There are currently almost 150,000 development jobs right now on one major job site, compared with only about 16,000 positions for DevOps. It seems that the revolution in which developers would be replaced with DevOps engineers never actually happened.

    In fact, and as we’ve previously argued, many people find that having DevOps on their job title actually harms them when it comes to finding the right job. In this article, we’ll look at why.

    The Death of the Developer

    The “death” of the developer has been prophesied for quite some time now. Ever since the creation of the concept of DevOps, in fact. The most vocal and prominent instance of this argument was offered by programmer Jeff Knupp back in 2014, who used a blog post to argue that the popularity of DevOps meant that programmers were increasingly unable to focus on what they do best: writing code.

    Instead, argued Knupp, the tyranny of DevOps was forcing coders to become generalists rather than specialists. They were being forced, he said, to include on their CVs an ever-growing number of “skill sets,” some of which were pretty tangential to their core role within an organization. Instead of traditional developers, it was feared, an army of “DevOps engineers” would rise who could just about do a wide range of tasks, but do none of them very well.

    In the interests of balance, it’s worth pointing out that Knupp—and many who have repeated his argument—have a vested interest in “defending” traditional coders against the rise of DevOps. It might be true that a thorough knowledge of GDPR compliance processes is not technically necessary for a developer, but some of the skills the DevOps highlighted—not least backend security—are best addressed at the development stage. Developers, in other words, shouldn’t be given a free pass when it comes to thinking about the way in which their creations are actually used.

    Adapt and Survive

    Nonetheless, the popularity of the concept of DevOps has forced many developers to adapt their skill sets, or at least the way they present them. Concepts such as CI/CD, segmentation of internal communication, automation and “continuous everything” have become central to the way many developers work and are highly sought after. We have DevOps to thank for that.

    In addition, the rise of DevOps has made room for an ever-expanding set of novel approaches. Five years ago, it seemed that a new approach to IT management was being developed once a month. First came DevOps, then DevSecOps, then QAOps. This explosion of new approaches does seem to be calming down, but they remain influential on at least two levels.

    The first is that, although none of these approaches (and arguably even DevOps, as we’ll see below) have developed into distinct disciplines, they have subtly redefined the way in which developers are understood by the average organization. The second is that, in this context, many developers have begun to stress that they have cross-cutting expertise. In other words, they have had to adapt the way in which they present themselves to survive.

    The Death of DevOps

    Because of this, we should see the rise of DevOps more as an evolution than a revolution.

    At the broadest level, DevOps has had a hugely beneficial effect on the process of software development. There is an expectation that developers will have at least a passing acquaintance with the systems and processes that IT teams use. This was not always the case in the past. Developers today have to know how things such as cloud IAM frameworks or APM platforms work, and why they are important for deploying and managing the applications that developers write.

    In this context, it seems strange that some coders ever worried that their job would be replaced. While it’s true that developers are now expected to have much broader skills than they did 10 years ago, organizations still need people who can actually code, and will do for decades yet (until we are all replaced with AI, that is).

    It seems that some of us were too eager to see a dramatic revolution, whereas the reality has been more subtle and much slower. And indeed, in many cases the “transition” to DevOps has been almost invisible: new graduates are now trained in the basic principles of DevOps, without this ever having become a discrete college course.

    Many of these new graduates, in fact, would be hard-pressed to define what DevOps actually is. But that’s not because it’s gone away; quite the opposite. It is now such a fundamental part of the way that most of us do our jobs that it is losing its identity as a separate idea. This means, eventually, that it will not be “development” that dies, but “DevOps” as a distinct addition to it.

    The Future

    In short, DevOps has not killed the developer, and there is no evidence that it ever will. Some of us, it seems, were being a little dramatic. On the other hand, DevOps has had huge effects on the way that developers work, because it points to the skills that the best developers have. For that reason, there remain tens of thousands of jobs for developers in the conventional sense.

    In short, developers work alongside DevOps engineers; they don’t compete with them for the same roles. So instead of seeing ourselves in competition, let’s try a little collaboration.

  • Solving the DevOps Dilemma in the COVID Era 

    Solving the DevOps Dilemma in the COVID Era 

    The coronavirus pandemic is forcing businesses to double down on DevOps transformation initiatives across the enterprise, pushing companies to be more agile and implement software changes throughout their organization at a much faster rate. However, too many IT departments rely on older, complex processes to approve software changes coming from DevOps teams and simply cannot keep pace with this accelerated rate. This is because many parts of the delivery process remain heavily manual, time-consuming and siloed. In other words, rather than realizing enterprise-wide transformations, the value from DevOps initiatives is remaining localized and doesn’t come close to delivering on the promise DevOps held in the first place.

    But because of the profound and sudden changes to the way we work, the industry is reaching an inflection point. Increased demand and competitiveness for modern digital experiences and ways of working are forcing businesses (even those within highly regulated industries) to rethink how they build software and get it approved faster. The need is clear among developers to reduce time-to-approval for new features, yet organizations must remain steadfast in protecting the business against rushed features that may not contain the proper safeguards and could negatively impact business operations.

    To help strike a balance during this critical time, a new trend to expedite software development and deployment is emerging: a platform-based approach to DevOps.

    Driving Visibility With Platforms

    The potential for platforms to streamline aspects of DevOps is profound. Platforms are able to model data and workflows to connect developers and IT continuously all along the development and delivery process. For example, the platform can leverage information from the flow to automate the manual and time-consuming change approval process, enabling them to release features rapidly and safely.

    But the benefits of platforms transcend beyond workflows. The vast number of tools used by developers and IT makes it difficult for leaders to get a holistic view of how each team is performing. This lack of visibility slows the behavioral and cultural change needed to succeed with DevOps. However, with the system of record and engagement that the right platforms provide, stakeholders on both sides of a project can easily view and audit the release process, which means shorter development cycles, increased deployment frequency and more dependable, high-quality releases.

    Companies, and even teams within the same company, are at many different stages of DevOps maturity. Some are fully adopting distributed teams based around products and simple development pipelines that make rapid, incremental changes, potentially multiple times per day. However, most organizations still have more complex releases that are still on a longer cadence such as weekly or monthly. Those releases may involve multiple teams and a wide range of development tools so again, the platform approach provides visibility and the ability to automate across the entire release.

     DevOps at Scale

    While many businesses are leveraging DevOps in various capacities, they have yet to be able to scale adoption across their entire organizations. This is the Achilles Heel for DevOps as a whole—after all, the goal with any transformative initiative is to scale, and traditionally DevOps has been difficult to scale past initial early successes.

    The challenge in scaling DevOps is that while there are many tools at developers’ fingertips, the actual processes around audit, compliance, security and change management are still often performed manually, and many of the tools are disconnected, meaning fragmented data and, yet again, limited visibility across numerous teams within an organization. At a time when controls should be becoming more decentralized, with more operational parameters ‘moving left’ to the control of development teams, we are instead seeing delays during deployment, difficulty driving best practices and DevOps adoption across the enterprise, and a lack of trust across teams.

    However, with a platform approach, the ability to scale is built into the technology since software approvals can be automated, enabling IT teams to allow more decision-making in development with appropriate guardrails. The IT teams can ensure the release of features rapidly and safely—and more importantly—focus on strategic, business-critical work.

    Resolving Data Configuration Challenges With Platforms

    In addition to unlocking visibility and scale with DevOps platforms, there’s a growing practice of leveraging platforms to improve configuration data. As companies shift to working in the COVID-19 era, they’re using more applications that require frequent updates. To ensure the applications don’t break in production, developers are automating application testing and deployment with platforms, allowing this process to occur earlier in the software delivery life cycle.

    However, ensuring configuration data accuracy during this process can be challenging. By using a platform for developers to add and consolidate configuration data, users can better control the application environment, prevent issues in production and quickly correct post-deployment problems. All this is possible by integrating machine learning into the platforms to prevent incorrect configuration data settings from reaching production environments. The machine learning identifies potential misconfigurations earlier, before apps are moved into production, ultimately helping users avoid app and infrastructure deployment inconsistencies.

    With platforms, developers can both improve the quality of configuration data and identify incorrect configurations using machine learning ultimately to prevent software changes from causing outages and incidents during a highly critical time.

    The Bottom Line

    The coronavirus pandemic has magnified the importance of agility and quickly adapting technology to meet changing customer and employee needs. As a result, enterprises are trying to figure out how to navigate and embrace new technologies that help ensure business resiliency. When done right, DevOps should help accelerate and scale this innovation, while still maintaining compliance and security. Adopting a platform-based approach to DevOps helps organizations reduce time-to-approval of new features so they can effectively drive digital transformation across the business—the North Star of all IT initiatives in this new work environment.