Author: Bill Doerrfeld

  • JAMstack Boards the Enterprise

    JAMstack Boards the Enterprise

    Set course for development via JavaScript, APIs and Markup. Engage.

    In recent years, the JAMstack web development trend has garnered interest among front-end web designers. A 2020 study by Netlify found 1 in 3 sites serving a million users use JAMstack.

    JAMstack has been viewed as a development style for blogs and startups, but lately, some proponents believe it’s time for enterprise adoption. So, what benefits could JAMstack and serverless offer enterprise architecture? I recently talked with Ryan Coleman, vice president of engineering and product at Stackery, to find out.

    Defining JAMstack

    First off, what is JAMstack? JAM stands for JavaScript, APIs and Markup. It’s is a new(ish) style for building websites and applications based on modern tools and serverless web architectures. We’ve seen its adoption grow exponentially within the last five years or so.

    As defined at jamstack.org, JAMstack enables fast and secure sites that pre-render files directly from a CDN. This avoids tight-coupling between the client and the server, also known as headless. Applied in the right context, it can bring performance, security, scalability and developer experience benefits.

    Admittedly, there is some variation on implementation of this style—PayPal’s Jamund Ferguson simply calls them static apps—but, “the thing that they all have in common is that they don’t depend on a web server,” noted jamstack.org. Jekyll, Hugo, Nuxt, Next and Gatsby are among many JAMstack frameworks and static site generators, and many adopters are listed here.

    JAMstack Benefits

    No longer are IT teams operating a web farm. Rather, they are shifting the process of interacting with live web servers left. According to Coleman, JAMstack is more aligned with these modern practices across the board. Therefore, he sees many potential benefits for its use within enterprise environments.

    Serverless

    With JAMstack, web pages are built during the build process attached to a CDN pipeline. “Instead of running a server farm, you are externalizing it,” notes Coleman. “It’s the CDN’s problem.”

    JAMstack plays nicely with a serverless mentality. “JAMstack helps rethink what production footprint actually looks like,” Coleman said. By reducing your active server footprint, serverless implementations decrease infrastructure costs.

    Security

    With the proliferation of web vulnerabilities, companies are seeking new ways to limit their exposure and avoid catastrophic breaches. JAMstack can help enterprises keep pace, offering a “much tighter place to apply security controls,” he said.

    It allows teams to think of their security infrastructure in smaller pieces, which affords better control and scalability for things such as authorization. “Serverless architecture helps enable enterprise-grade SAML-based Auth tied into your stack,” Coleman noted.

    Democratization Effect

    Coleman also sees opportunities for small teams to disrupt the dominant players by utilizing it. “Companies need to move quickly, achieve enterprise-grade architecture and secure products with less investment on the onset,” he said. These abilities could, for example, enable a FinTech startup to compete on the same playing field as an established bank.

    “How do you create an architecture that is living, and how do you make sure it is as secure and clean as possible?” he asked. “How do you get a whole team together where actually doesn’t have to use 1,000 lines of YAML, and how do we continue to maintain?”

    Since JAMstack adopts APIs, companies could rapidly stitch together high-performing applications. Furthermore, by pairing low-code tooling and JAMstack, teams could drag-and-drop snippets of AWS-managed services to construct web applications very quickly.

    Bi-Directional Interactivity

    JAMstack has a reputation for creating compelling user-facing apps. Yet, Coleman acknowledged a common misconception: JAMstack is static and, therefore, not for enterprise.

    However, JAMstack can be more than a static app; the structure can support secure interactive capabilities. By taking CDNs and buckets and utilizing API connections to rich features such as AWS managed services, it can essentially reach the same enterprise-grade capabilities as other development styles, he said.

    JAMstack: No Longer Only for Blogs

    “Serverless + JAMstack is where web app architectures are going,” Coleman wrote in a recent blog post. Though many view it as a static app, there is growing potential for using this development approach to enable applications with dynamic interactivity. “With AWS in the backend, you can create an interactive enterprise-grade app.”

    Another benefit of JAMstack is the decoupled nature between client and server. This abstraction layer makes for building web applications across multi-cloud arrangements. And as web APIs become more accessible through low-code, the entry barrier to connecting to a MySQL or Postgres database—or handling identity management, for instance—is lowering.

    Once only viewed as good for blogs, JAMstack is gaining more credibility within enterprise architecture as APIs and serverless become more commonplace, offering the potential to increase performance, increase rapid web application delivery and solve other concerns within enterprise situations.

    Coleman described JAMstack as enabling developers to “build that web application the way you want.” How, then, do you want to build?

  • How ‘Some-Code’ Platforms Perform a Balancing Act

    How ‘Some-Code’ Platforms Perform a Balancing Act

    Recently, there’s been a surge of interest in visual programming models, all with varying degrees of user-friendliness. These low-code platforms utilize drag-and-drop elements to help citizen developers stitch together applications, avoiding the complexities of hard-coding connections. Such platforms are crucial amid a developer drought and shine in their usability. But, how usable is too usable?

    “A low-code platform should abstract complexity, yet always offer a way under the hood,” said Jesse Orshan of WayScript. In other words, the platform should never get in the way of advanced mechanics. To do so, “some-code” platforms balance usability and customizability.

    I recently spoke with WayScript co-founders Jesse Orshan and Lane Eden to see how some-code combines traditional coding and low-code. As opposed to a 100% visual no-code experience, some-code focuses on operational automation while granting a peek under the hood. Read on to see how the notion of “some-code” may set itself apart from the larger visual programming movement.

    Why Just ‘Some-Code’?

    To understand some-code, consider the greater industry. As I recently covered, many factors are spurring a low-code revitalization. One is the need for rapid development for internal tools. Orshan acknowledged how “cumbersome, costly, and time-consuming it is to build and maintain internal tools.”

    Many developers are fully capable of, for example, programming a native iOS app. Yet, turning that into a business application with a back-end running in the cloud with the proper databases, server arrangement, access management, and continuous deployment strategy is a whole different story.

    “The idea is to blend coding and low-code,” Orshan said. “Scaffolding is the most difficult part of development.” Therefore, a some-code platform provides an operational toolset—a framework that enables developers to focus on their application logic.

    Some-Code Leverages Event-Driven Architecture

    Event-triggering has become common within modern programming. Triggering is necessary for automating tasks and workflows involving interconnected tools.

    For example, say an internal tool for a sales department must automatically update a lead spreadsheet and send a Slack notice once an email is received from a prospective client. This process requires scripting a series of API queries involving Gmail, Salesforce and Slack APIs.

    Though the logic seems simple from the outset, hooking together applications is not a trivial task. “Building a robust triggering system that can scale with your load is a very complicated thing to do,” said Eden. HTTP API integration is a unique skill that not all possess. “Thereʼs an understated art to building good APIs,” according to an Increment blog post.

    The hurdles of API integration have already given rise to drag-and-drop workflow services such as IFTTT and Zapier. Some-code applications, too, could quickly enable developers to mix-and-match APIs in the programming language of their choice.

    Other Some-Code Benefits

    Internal tooling can be a big pain point. It’s “bespoke and custom to every business,” said Orshan. Utilizing drag-and-drop components alongside an IDE, some-code could lower the DevOps barrier for constructing enterprise-grade interconnected applications that require testing, auto-build and deployment automation. Here are some other some-code benefits:

    • Abstracted type system: APIs are at the heart of many low code initiatives, enabling integrations with third-party tooling to enable event-based modeling. Some-code could enable developers to program logic without hardcoding integrations, offering a “unifying system abstracted type system,” noted Orshan.
    • Flexibility: A unique prospect of some-code is that it could retain the programming language developers are accustomed to.
    • Aids rapid development: Some code seeks to abstract things away, making it easier for developers to quickly solve core problems.
    • Fill integration talent gap: A lack of specialized talent encompasses integration engineers and IT security disciplines. According to OutSystems, 45% of businesses adopt low-code to reduce dependency on hard-to-hire technical skills.

    The Reality of ‘Citizen Development’

    Problem-solvers come in all skill sets. Some are programming novices with little know-how, and UIs cater well to this group. However, only 8% of companies say they have business users utilizing a no-code platform without IT intervention, according to OutSystems’ 2019 State of Application Development report. Instead, the majority of low-code users are professional IT developers, at 69%.

    “There is a place for visual elements, and there is a place for coding,” said Eden. “Sometimes, writing a function in Python is just way more efficient.”

    Though low-code providers may trumpet the citizen development ideal, in reality, in 2019, only 20% cited enabling citizen developers as a key reason for adopting low-code. Perhaps this need will increase subsequent a fully remote economy and a developer talent shortage. Yet, as of now, experienced software developers are the ones using and benefiting from low-code tools.

    Final Thoughts

    The usability of no-code empowers business technologists to build basic workflows, yet lacks deep customization abilities. Yet, pure manual programming slows when you consider the many web APIs, differing standards and DevOps tooling integrations necessary to deploy modern enterprise-grade cloud applications.

    The premise behind some-code is to help skilled developers stitch the operational scaffolding around their source code, helping integrate, validate, test and deploy software in a more streamlined approach. This style could be a better balance for advanced developer teams requiring an extra push.

    “Our guiding philosophy is there should always be a way to get under the hood,” said Orshan. “The platform should never get in the way.”

  • Low-Code: An Oasis During Developer Drought

    Low-Code: An Oasis During Developer Drought

    Key insights from Mendix’s 2020 Developer Drought Index

    You may have heard that Silicon Valley is in the midst of a developer drought. But the Valley is not alone; developer talent across the U.S. heartland has dried up. In fact, the top 10 U.S. counties with the highest developer demand per capita aren’t even in California.

    A recent report by Mendix identified new hiring hotspots and a changing U.S. map for tech talent. States in the U.S. heartland are actively seeking developer talent, though some are slow to adopt 100% remote work. In the wake of COVID–19, many are reassessing work-life opportunities, leaving densely populated cities to work and live in more rural areas.

    I recently had a great discussion with Sheryl Koenigsberg, head of global product marketing at Mendix, to make sense of the “Developer Demand Index” findings. Below we speculate on the future of developer work, and how low-code platforms may be the oasis many talent-thirsty companies seek.

    ‘Developer Demand Index’ Study

    The “Developer Demand Index” sought to identify locations where developer talent is needed the most. The process involved a geographic analysis of 2,000 of July 2020’s job ads for U.S. software developers.

    The study found high developer demand and short supply in middle America; South Dakota, Nebraska and Utah were among the top states with the lowest supply to demand.

    At a county level, the highest developer demand was in Cumberland County, New Jersey; Minnehaha County, South Dakota; and Pontotoc County, Mississippi.

    The study demonstrated how more established tech hubs—Silicon Valley and Austin, for example—have a better balance of talent demand and supply.

    “The study confirmed unpopular theories that I had,” said Koenigsberg. “Developer drought is not a Silicon Valley or coastal-only problem; smaller metros throughout the country are experiencing the same problem.”

    Conditions for a Drought

    Why do states in the nation’s heartland have a developer drought to begin with? I assumed that a lower average salary in middle America would deter developers, but Koenigsberg said the conditions are more complex.

    “I don’t necessarily see a correlation between average salary and developer drought,” she said. Rather, new tech hubs continue to form wherever larger enterprises can get tax breaks. Other regional perks could include local government startup incentives or university partnerships.

    Tech certainly has a history of revitalizing less dense areas with new hubs. Take Google’s expansion into Austin, Amazon’s takeover of Seattle’s South Lake Union neighborhood or SpaceX’s remote Starship site in Boca Chica, Texas. Naturally, these areas attract the requisite talent and encourage other companies into the fold as well.

    For example, the report speculates South Dakota state could be a new Silicon Prairie hotspot. “A vibrant tech & startup scene, local talent, and the lowest COVID–19 rates are all driving the economic surge in this state,” read the report.

    With remote work and social distancing brought on by COVID–19, technology companies are adapting and the urgency to cluster in certain locales may dissipate.

    COVID–19 and Remote Work

    Software was already eating the world. But with COVID–19, it’s eating physical reality itself.

    With COVID–19 forcing many companies 100% online, the need for new software is skyrocketing like never before. Google, Facebook and many others have enacted stay-at-home plans for most of 2021. After the crisis, remote work will be a more permanent reality for many.

    While COVID–19 benefited tech, many brick-and-mortar businesses were less prepared. We’re now seeing the frailties of old systems, described Koenigsberg, and the need to replace paper-based or manual operations with digitized versions. Consumer-facing companies that did not vigorously embrace digital transformation before COIVD–19 are now in a tight spot.

    Low-Code Waters Fill a Developer Drought

    According to Derek Roos, CEO of Mendix, “the ‘Developer Demand Index’ shows that companies need to think differently about how and where to engage skilled tech workers in 2021 and beyond. Traditional development paradigms basically fall apart when you’re dealing with mobile or remote workflows.”

    As I covered recently, COVID–19 is only one of many factors spurring a low-code revolution. By utilizing visual-based models, “citizen developers” can construct applications. This enables a business analyst, for example, to string together an internal application without jumping through the traditional IT hoops. Koenigsberg identifies other low-code benefits:

    • Hire Local: If tools are less impenetrable, companies can retrain local employees, helping recover the developer gap and negating the need to hire externally.
    • Collaboration: Low-code aids remote work, enabling pair programming where teams work on the same model simultaneously.
    • Domain Expertise: Citizen developers with niche domain knowledge can better optimize applications to their industry needs. Knowing a factory production yield, for example, can help better construct a manufacturing application.
    • Women in Tech: Koenigsberg notices significantly more female involvement at low-code themed events. Hopefully, low-code can have a balancing effect on gender participation in tech.

    Final Thoughts

    The Mendix “Developer Drought Index” revealed areas of high demand and short supply throughout the U.S. Interestingly, 92% of the job ads analyzed in the study required a specific location. Regardless, the report concludes there are compelling “opportunities for companies and individuals to decentralize talent away from established tech hubs using virtual teams and cloud technology.”

    Low-code seeks to democratize software development to keep deployments on pace with the intense demand for software. Of course, low-code is no cure-all, and Developer Drought locations will likely still seek external or offshore hiring to supplement. However, low-code may offer the respite needed during uncertain times.

  • 7 Forces Driving the Low-Code Movement

    7 Forces Driving the Low-Code Movement

    Why low-code? Why now? Here are some of the driving forces behind the burgeoning low-code movement

    If you’re keeping an eye on the tech tooling landscape in 2020, you may have noticed the buzz around low-code. Countless low-code platforms are being funded and coming to the market. In fact, Forrester estimates that spending in the low-code category will exceed $20 billion in 2022.

    But, arguably, visual programming models are nothing new; FileMaker is 35 years old, for crying out loud. WYSIWYG web editors are just as old. Providers including Outsystems and Appian have similarly supported visual code generators for decades. So, what’s with all the low-code hype? Why low-code, and why now?

    Well, a new generation of low-code is emerging, spurred by some unique forces. I recently talked with Peter Nelson, vice president of Claris, an Apple subsidiary, and maintainer of FileMaker, on the current market factors driving advances in the visual programming space.

    Low-Code, High Interest

    Below, we brainstorm top forces stimulating the low-code trend, from a pressure to automate internal processes to a lack of developer talent and COVID–19. This list is not exhaustible, but hopefully offers a window into why the low-code movement is gathering steam.

    Rapid Development

    There is a pressing need to automate internal processes to maintain business agility.

    Release velocity is quickening. Across the board, all companies face the need to automate their internal operations. Companies require workflow automation for form generation, data retrieval and database-driven functional apps, among other things.

    The low-code industry had become a bit stale up until about five years ago when things started to change rapidly, Nelson said. “Recently, we’ve seen an explosion in the low-code no-code space.”

    The emergence of next-gen low-code tooling runs parallel with the emphasis on rapid, continuous-release strategies. New UX layers that appeal to citizen developers empower more actors within an organization to embrace DevOps and enable quicker deployments.

    Lack of Developer Talent

    Businesses lack programmers with proper skill sets.

    Code.org tracks 666,534 open computing jobs nationwide, yet only 71,226 computer science students graduated into the workforce last year. That means roughly 89% of open positions cannot be filled with the talent on hand.

    IT faces a labor shortage. Drag-and-drop visual models enable problem solvers to quickly string together a workflow, avoiding tracking down the right IT department or PHP developer.

    Nelson feels low-code can rectify the labor gap and act as more than just a temporary bandage. “You aren’t sacrificing long-term viability,” he said. “These aren’t temporary solutions that you need to grow out of.”

    Cloud Integrations

    Nuances of cloud integration workflows are challenging to maintain.

    Think of all the cloud-based business utilities an average user consumes: Slack, DocuSign, Dropbox, Google Drive, Salesforce, etc. If a problem solver is automating a unique internal process, they’re likely creating an event-driven workflow between these apps. This means cloud integrations have become very important.

    Web APIs do offer a standard communication format between cloud-based microservices. However, each connector has its nuances, and manually programming actions between them can be time-consuming. Not to mention the implications of supporting third-party dependencies such as authentication time-outs, versioning breaking change and uptime monitoring.

    “Integration within no-code did not exist 10 years ago,” Nelson said. Fast forward to 2020, and ProgrammableWeb cites 23,000 public APIs. Low-code platforms have emerged as a glue between properties, solving the integration hurdles.

    “You can build anything with the right legos,” he noted. Similarly, workflow automation requires stringing together the right components. “You don’t need to be a developer to do this.”

    Hybrid Modes

    Hybrid styles mean platform-agnostic development layers become more important.

    Hybrid cloud, multi-cloud, multi-device. The world is accessing data from multiple sources and storing it in multiple places. Thus, business applications must be flexible in a platform-agnostic world.

    A 2012 Cisco Systems study found 95% of organizations allow employee-owned devices. In 2016, Systonic found 87% of businesses rely on workers to access their smartphones. Now in 2020, a fully remote economy clocks in to work on their personal devices from home.

    In this remote paradigm, web-based collaboration is an absolute necessity. Users should encounter the same digital experience regardless of the device used or where they’re located. However, even though users are remote, not all servers are remote.

    “We’re slowly shifting toward cloud-native,” Nelson said. “But on-premise[s] still takes the lion share.” With concern looming over container-based cloud deployments, some high-security institutions could remain on-premises for some time.

    Thus, business workflows require platform-agnostic capabilities that can talk with both on-premises and cloud-native servers. Low-code platforms are acting as an agnostic layer, catering to these hybrid modalities.

    Artificial Intelligence

    Low-code democratizes access to machine learning and AI.

    “Today, you can learn how to stand up a database and interact with it from a YouTube video,” Nelson noted. “However, you can’t integrate AI, or scale it easily. The problem statement has changed.”

    Low-code platforms abstract the back-end complexity of AI, enabling object recognition, language analysis, predictive analysis, risk scoring and other abilities. Some even can train new machine learning (ML) models.

    Low-code enables companies to leverage powerful AI without much investment. For example, Outside Insight recently reported how low-code platforms are democratizing AI, while consulting firm Delloite assembled TrueVoice, a voice analytics platform built on a low-code platform using behavioral and emotional AI.

    “If you can attach machine learning to the automation of business processes, I think you change multiple industries,” he said.

    COVID–19

    COVID–19 amplifies the pace of digital transformation.

    Digital transformation has always been there. But now, you can’t ignore it. “COVID isn’t actually changing anything, it’s accelerating things,” said Nelson.

    In the wake of COVID–19, companies may wholly depend on virtual business. For example, Take Allstate Insurance, which now receives 90% of claims using virtual tools, up from 11% in pre-COVID times. Low-code helps these brick-and-mortar companies quickly onboard to new technologies.

    To supplement traditional business models, some industries will take digital transformation even further, becoming legitimate tech companies with externalized SaaS. For example, take speaker designer Dolby’s transition to online media transformation as a service.

    Reusability

    Next-gen low-code emphasizes reusability and externalization more than predecessors.

    Anyone who follows the Bezos mandate of externalization from day one knows how valuable internal infrastructure can be. The tools you build should always be reusable by anyone on the network.

    So, if you’re introducing an abstraction layer to build new software, you don’t want to shoot yourself in the foot. Low-code has a potential downside of inhibiting code ownership and stunting the ability to externalize valuable infrastructure.

    Whereas older low-code platforms may have caused these concerns, Nelson views modern platforms as more malleable. He noted that with low-code widgets and data accessible via APIs, “internal processes, management work, by definition, are exposable.”

    A Low-Code Revitalization

    Low-code, no-code, some-code, workflow automation; call it what you will. Citizen developer platforms have taken on much interest (not to mention much funding) in recent years.

    The need for increased accessibility to advanced workflow automation seems to underpin the low-code movement. But what else is powering recent transformations? To review:

    • Rapid automation: Companies need to create frictionless business processes easily and rapidly, and change them on the fly.
    • Developer scarcity: The workforce lacks qualified candidates. Low-code fills this gap in the market.
    • Integrations hurdles: Internal apps involve many cloud integrations. Low-code can support these connections, enabling users to link event-driven workflows visually.
    • Hybrid requirements: Users demand ubiquitous network access no matter device or cloud type. Low-code can act as an agnostic layer.
    • Democratization of AI: AI empowers analytics and business intelligence projects, yet machine learning is difficult to implement. Low-code is abstracting this complexity.
    • Reuse and externalize: Newer low-code platforms are better designed to expose data and services.

    All this adds to a confluence of forces, giving rise to a low-code tidal wave. “This is the time where everything is coming together and is possible,” said Nelson.

    What do you see as spurring our current generation of low-code?

  • Top Pressing Concerns for CI/CD in 2020

    Top Pressing Concerns for CI/CD in 2020

    The tech landscape is changing rapidly. With the need for increased development velocity, CI/CD has become ubiquitous among most organizations. Yet, with the growing number of microservices, CI/CD may be tough to wrangle without the right strategy.

    At the same time, it’s difficult to keep pace with the constant evolution around CI/CD. So, what is the state of the CI/CD space in 2020, especially in these turbulent times? What do stakeholders see as top pressing concerns companies should consider to advance their release fluidity?

    For this article, I interviewed two stakeholders on the latest trends and industry cooperation around CI/CD. Read on to discover what two CI/CD thinkers, Tracy Miranda, board chair, Continuous Delivery Foundation (CDF), and Lachlan Donald, CEO, Buildkite, see are pressing concerns for CI/CD in 2020.

    More Microservices, More Problems

    With the number of microservices rising to the hundreds (or thousands) for some enterprises, maintaining consistent release strategies across the board could easily become a nightmare. If the goal is to replicate a unique CI/CD pipeline per microservice, pipeline automation and configuration management become top concerns.

    “Automation will be key,” said Miranda. “We can no longer afford to be writing each CI/CD pipeline by hand; we will need new approaches.” She added that recent industry discussion shows “configuration management is a top concern for CI/CD practitioners.”

    Tools like Jenkin X could enable this sort of automation, she noted. Companies should consider evolving their CI/CD pipelines with better configuration management.

    Platforms Must Evolve

    The recent “State of the Cloud Report” from Flexera found 39% of IT leaders saw implementing CI/CD in the cloud as a top priority. According to Miranda, the global crisis seems only to accelerate the need for cloud and CI/CD automation.

    But, traditional CI/CD platforms aren’t always suited for modern development workflows with numerous pipelines. For Donald, an evolution in new tooling is absolutely necessary to help companies keep pace.

    “We’re at a point where organizations need to completely rethink their approach to CI/CD,” Donald said. “Traditional CI/CD platforms are not suited for modern development workflows.” He cites slow speed, unreliability, scalability limitations and security risks as common hangups among many CI/CD tools.

    Lack of Clarity in CI/CD Market

    The market has expanded significantly to address the gap in CI/CD tooling effectiveness. According to Miranda, this has led to a continuous deployment tooling ecosystem wrought with interoperability and competing styles.

    “My biggest concern is the proliferation of tools and platforms with a lack of interoperability and lack of clarity of how to best use them or whether they are fit for purpose,” Miranda said.

    These differences make it difficult for developers to find the right integrations that work for their environments, leading to wasted time and effort. “Developers will experience growing pains with their CI/CD platforms as they work to keep up with the constant demand for quality software,” acknowledged Donald.

    Lack of Standards

    Part of the lack of clarity resides in the fact that there are little to no standards emerging in the CI/CD space. Aside from Accelerate rising as the “bible” for software delivery, Miranda sees a lack of standards in the CI/CD space.

    “Not having standards or de facto standards is a problem,” she said. “For example, why is there no de facto standard for reporting pipeline test results?”

    Advancing Open Source CI/CD Tools

    To improve Interoperability throughout the CI/CD industry, bodies such as CDF are working on setting general guidelines. Miranda described how CDF is accomplishing this, by supporting a CDF Interoperability working group, sharing CI/CD practices and maintaining open source CI/CD projects. Two CDF projects she finds quite compelling are Tekton, a pipeline execution engine, and Jenkins X, a new CI/CD platform for pipeline automation.

    Cloud vs. On-Premises: A False Dichotomy?

    In analyzing the CI/CD tooling ecosystem, Donald recognizes a recurring dichotomy; that companies must choose between the security of on-premises and the speed of cloud-native. In reality, this dichotomy may be false.

    “It is possible to have the best of both worlds,” he said. “A hybrid strategy [is] the solution for testing and deploying software at scale without compromising security or performance.’

    As opposed to cloud tooling, self-hosted CI/CD control planes could grant developers more code control and help meet security standards. “I believe self-hosted agents are always a good idea,” Donald said.

    As we recently covered, a hybrid cloud approach is picking up steam. Similarly, Jenkins X is designed to run on any Kubernetes cluster, regardless of on-premises or cloud, demonstrating industry movement toward tooling neutrality and hybrid motivations.

    Moving Beyond PASS or FAIL

    There is a reductive tendency in CI/CD to simply check whether a build passed or not. But, this mindset misses an enormous amount of useful information and undervalues the test and release suites themselves.

    “Teams should get granular about what worked and what didn’t,” Donald said. DevOps teams must evolve beyond a “PASS or FAIL” mindset to analyze more minute aspects of the build process itself.

    For Donald, this also means shifting to treat test code performance “as a first-class citizen, applying modern development and scaling practices to it and allocating the necessary resources to it.”

    Future Evolution: Progressive Delivery and Hybrid Approach

    In closing, I asked Miranda and Donald their thoughts on the future CI/CD evolution. They shared their perspectives on where CI/CD needs to evolve.

    Miranda views progressive delivery as the next milestone. With progressive delivery, teams deploy services in a staged manner, she said. “Tools, technologies and processes that fall under the ‘progressive delivery’ umbrella will be the next milestones for improving deployment speed and efficiency.”  Building blocks such as services meshes could help advance this process, she noted.

    Donald stressed the need for a hybrid approach to CI/CD. A neutral control plane could grant better control and future-proof continual release strategies.

    Assessing the CI/CD Landscape

    In summary, our panel shared thoughts on the top concerns for CI/CD in 2020:

    • Platforms must evolve: Teams should rethink their approach and emphasize automation in pipelines.
    • Lack of clarity: There are few standards and a lack of clarity among tools. This confuses developer adoption.
    • Interoperability: A focus on interoperability is critical toward advancing the industry.
    • Unhelpful dichotomies: The cloud-native versus on-premises divide may not be helpful for a hybrid strategy; thus, it’s recommended to seek out platform-neutral tools.
    • Move beyond PASS or FAIL: Switch the mindset to “Test code = application code.”

    High performant organizations must scale their technology tremendously. With this desire comes a mounting strain on how companies adopt a continuous deployment strategy. Without a proper CI/CD plan, business agility is sacrificed.

    As an ending note, I absolutely love Donald’s statement: “A good litmus test for how well a company is run is their approach to CI/CD.” Perhaps what all can agree on is that companies must prioritize CI/CD, as it is now business-critical. Otherwise, deployments may be numbered for those organizations that don’t adapt.

  • 3 Key Issues With Hybrid Cloud Transformation

    3 Key Issues With Hybrid Cloud Transformation

    The cloud has fractured. Nowadays, it is nearly impossible to scale a cloud-agnostic digital transformation initiative. The reality is that most enterprises adopt a hybrid cloud arrangement. Whether designed strategically or throughout years of competing vendors and technology influences, hybrid cloud environments, and the problems therein, seem a mainstay for modern IT.

    Many digital transformation efforts are culminating in hybrid cloud scenarios. 451 Research recently found 72% of enterprises are already using more than one cloud vendor. As one can surmise, competing standards and inconsistencies among cloud tooling can cause headaches for developers, security teams and potentially even end users.

    3 Common Cloud Transformation Problems

    I recently met with Jeff Kukowski, CEO, and Grant Ho, CMO at CloudBolt Software, to identify issues within today’s cloud transformations. According to CloudBolt, custom coding, governance concerns and cybersecurity incompatibilities are among the top problems that hold back cloud transformation (or make it very costly). Below, we’ll see what strategies they recommend to solve these problems.

    1. Custom Coding

    In 2020, a software-defined approach seems the obvious preferred choice for most IT professionals. Yet, custom code is still a significant struggle for hybrid clouds. The Standish Group research shows 19% of projects will be canceled before they ever get completed. Further results indicate 52% of projects will cost 189% of their original estimates. Custom code decreases reusability and creates redundancy.

    2. Lack of Governance

    With many disparate cloud applications, it can be difficult to set standards. There is not much control. This free-for-all can directly impact the business. Lack of visibility into resources, a related concern, could cost a business significant expenses. Citing a recent Gartner study, ParkMyCloud estimates that companies waste $8.8 billion on idle cloud resources each year.

    3. No Role-Based Security Policies

    Gartner found that 33% of enterprise security attacks are happening from people using resources in the cloud and not necessarily putting the proper governance and security parameters in place. Without role-based access control (RBAC) and a standards-based way to apply RBAC across all your resources, hackers can more easily penetrate a hybrid cloud.

    How Hybrid Cloud Affects DevOps

    These above problems are quite broad, but they reflect a culmination of many roadblocks along the development pipeline. In terms of DevOps, juggling the ever-growing variety of hybrid cloud tools could easily stunt deployment velocity.

    Kukowski described how cloud IT faces a plethora of tooling styles. They include on-premises tooling, serverless, infrastructure as code, Terraform, Kubernetes and backup as a service. “Greater than 70% of organizations are not only multi-cloud, but they are multi-tool,” he estimated.

    Naturally, supporting nuances between them becomes tricky. Not only must you recognize governance and security inconsistencies between platforms, but you must maintain them “into Day 2,” he said.

    Solution: Policy-Based Automation

    With hybrid cloud tooling now a reality for most enterprises, managing them becomes the next logical step. Solutions primarily revolve around better automation to increase self-service capabilities. For Kukowski, the answers lie in automated governance, heightened tooling visibility and implementing enterprisewide security policy services to automate security compliance and decrease custom coding.

    One way to achieve these benefits is by utilizing a Cloud Management Platform (CMP). Gartner’s 2020 Magic Quadrant for Cloud Management Platforms includes CMPs from CloudBolt, Embotics, Flexera (formerly RightScale), HyperGrid, Morpheus Data, Scalr, and VMware with vRealize Automation Cloud plus CloudHealth. A CMP layer could help automate self-service IT, assisting engineers to do their work with governance and security capabilities in place.

    Using a CMP, companies could eliminate custom coding for things such as access control. Such increased visibility could, for example, significantly decrease AWS server cost by reducing unused deployments. A CMP can benefit CI/CD too. Home Depot, for example, uses a CMP to greatly improve efficiency, decreasing infrastructure deployment time from weeks to hours.

    “Who is authorized to perform that action, on that K8s container, local VM, or cloud machine? We need visibility into that,” Kukowski said. “What is it doing? When is it running? Who has visibility to shut it down?” He recognizes that deep industry expertise is required to abstract complexity and standardize governance across all these situations.

    Streamlining the Polymorphic Cloud

    Saturated within an overabundance of cloud tooling, it’s easy to lose sight of your enterprise’s IT policies. Without global DevSecOps standards, security for hybrid cloud becomes risky.

    Enterprises with multi-tool environments are also at risk of wasting development time and effort. “We want to make sure the market does not repeat the problems of the past,” Kukowski noted. “Why custom code the fundamentals that operate your business?”

    Instead, companies should seek to reduce redundancy and eliminate custom code for each point to point integration. However, abstracting such complexity involves porting governance standards across all environments—a challenging feat for internal teams.

    The solution could lie in utilizing an external CMP layer. Such a layer could offer a software-defined approach to eliminate custom coding, offering policy-based security controls that consider the organization’s needs.

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

  • How to Use Microservices To Evolve DevOps Pipelines

    How to Use Microservices To Evolve DevOps Pipelines

    Enterprises are quickly becoming an intricate mesh of many applications. As companies create more and more microservices, their deployment environments are becoming increasingly elaborate. Without proper configurations, a microservices road map could quickly become unmaintainable.

    According to DeployHub CEO Tracy Ragan, if development teams are pushing points to a cluster continuously, application development can suffer without high visibility into their dependencies and application interrelationships.

    In her recent talk, “Evolving Your Pipeline for Microservices with DeployHub,” presented by the Continuous Delivery Foundation (CDF), Ragan, also Governing Board member of CDF, discussed ways in which teams can obtain improved insight into microservices delivery pipelines.

    Microservices Tracking Issues

    A 2018 study conducted by O’Reilly found that 86% of respondents reached mild success in adopting microservices in production. Only 15% reported “massive success.” These results demonstrate both the excitement surrounding microservices and the rarity of flawless execution.

    “I’m a huge fan of microservices,” said Ragan. “This is an exciting time to be in software development.” Microservices break from the traditional software delivery model, she said, forcing teams to emphasize the runtime. However, with this shift, it becomes easy to lose the logical views between applications.

    According to Tracy, dependency tracking and version control are top issues in maintaining microservices arrangements. With continuous updates, it can be challenging to keep track of which version a service is using. “Microservices development falls apart without a coherent management approach,” she said.

    Losing Visibility Moving From CI to CD

    Part of the loss of visibility stems from the move from CI to CD. Continuous integration (CI) involves routinely updating source code and starting the compile process. This is often done every hour, as opposed to every week or month. With traditional CI, the system created a package and scanned for dependencies at compile. This was the first step in the continuous journey.

    However, nowadays, microservices are typically linked at runtime or in the Kubernetes deploy file as part of a continuous delivery (CD) processes. In doing so, we’ve lost a certain amount of visibility that CI granted. Ragan likened it to “hammering a wine glass”—we still have the constituent parts, but they lie shattered in pieces.

    Large microservices suites of 50, 100 or even 300 are not uncommon these days. Such large ecosystems require logical tracking of versions and dependencies. Ragan argued that development teams need a workaround layer to replace the critical configuration management lost in CI compile reports. Visibility into interrelationships is necessary to trace how changes in one service will impact other applications.

    Enter Ortelius

    Ortelius is a package that helps with continuous microservices management. Ortelius, named after Abraham Ortelius, the inventor of the first atlas, helps trace the connections between services to improve an ecosystem’s visibility.

    To get an idea of how it behaves, consider an e-commerce store. To reach an evolvable microservices pipeline, each microservice should be independently deployable with its own workflow. For example, an e-commerce store may require a product microservice, payment microservice and an authentication microservice. These reusable components are independently deployable but rely upon one another to function as a whole.

    At a macro scale, an enterprise with thousands of inter-application dependencies would visually resemble a constellation of nodes. An extreme example of this may resemble the Netflix Death Star, a mass conglomeration of intersecting points. Ortelius grants transparency into an otherwise tangled mess as an “internal marketplace for microservices,” said Ragan.

    Paring Ortelius With DeployHub

    Ortelius is the open source core of DeployHub, an open source SaaS for sharing and releasing microservices. Ortelius, paired with DeployHub, enables teams to see the logical application map, exposing the complexity of microservices dependencies.

    Developers add DeployHub to any existing microservice development workflow prior to release. Ortelius is then called to increment the service and record dependency information. DepoyHub then uses for Helm or Ansible for the actual code push, and adds the record metadata and adds the tracking and mapping layer. Having such information is still critical for reporting like dif reports or a bill of materials report, noted Ragan.

    This sort of solution, Ragan proposed, is also vital for continuous configuration management—when a microservice changes, the team will always be aware of the new application version.

    The New Microservice Pipeline Model

    As noted above, in the traditional model, DevOps teams map dependencies in the CI stage. When an API developer publishes to the main catalog, they define specific attributes based on the microservices. A versioning engine will then typically map to visualize dependencies.

    Ragan outlined steps for a new microservices pipeline:

    1. Build image: Compile and build the container image.
    2. Put into registry: Quay or Docker registry. Specific for container registries.
    3. Track service-application configurations: This is where we collect configuration data to map the structural relationships.
    4. Push to cluster: DeployHub helps to standardize this process across an organization.
    5. Collect feedback: Configuration reporting and impact analysis.

    Core to this process is being able to independently deploy microservices and aggregate useful information. Of course, this is an incomplete model—a complete pipeline would utilize other steps including testing and automated security scanning as well.

    Benefits

    By streamlining the microservices journey in this way, repos will be broken out and teams no longer go through one big long workflow. According to Ragan, the visibility garnered from this method could help organizations in multiple other ways:

    • Reduce time: Ragan estimated automated application relationship mapping could replace one to two hours of manual work per week per development team.
    • Reusability: Decomposing applications into their domains aids reusability across an organization.
    • Avoid redundancy: Code sharing can significantly reduce duplicated code, thus avoiding redundancy and increasing flexibility.
    • Visibility: Detailed application to service relational knowledge could empower SREs to make better data-driven decisions.
    • Centralize: Helps standardize container deployment processes regardless of cluster type or collection, aiding both traditional and containerized microservices deployments.
    • Versioning: Improved insight into versioning helps when you need to share services externally.

    Lastly, what’s nice is Ortelius is open source on GitHub. Ortelius adopts an open community format to accept feedback. “Democratization is the core reason we have open source,” said Ragan. Ortelius can be used for free, or with added features from DeployHub pricing for enterprise cases.

    A Confluence of Software Delivery Styles

    Managing continuous software delivery across many microservices leads to unprecedented issues. In solving these issues, the industry appears to be fracturing slightly. For example, the model promoted by Ragan is in contrast with a recent presentation I covered from Codefresh.

    Where Ragan suggested improving visibility into independent microservices deployment pipelines, Dan Garfield of CodeFresh suggested adopting a single CI/CD pipeline to operate all microservices from a single control plane. As it goes so often in software tooling, the use case will likely dictate adoption.

    Whatever the software delivery process, when decomposing applications—or “taking the hammer to the wine glass,” as Ragan called it—we probably shouldn’t sacrifice visibility into the metadata associated with application versions and service to application interrelationships. If such data is lost or not managed correctly, we could lose a lot of potential value.

    For more information on evolving DevOps pipelines, watch the CDF-presented webinar here. DeployHub also published an adjacent article on this subject here. You can also contribute to Ortelius on GitHub.

  • How to Scale Microservices CI/CD Pipelines

    How to Scale Microservices CI/CD Pipelines

    As opposed to a traditional monolith, microservices architecture can theoretically bring many benefits. Microservices decouple software elements, enable reusable components and allow independent development cycles. However, in practice, microservices are prone to many issues.

    For example, teams accustomed to a traditional monolithic build process may find it difficult to reshape their established practices. Furthermore, as the number of microservices increases into the hundreds, managing separate CI/CD pipelines for each service becomes untenable, especially as DevOps components aren’t always optimized to fit every pipeline precisely.

    These are some of the real-world problems that Dan Garfield, chief technology evangelist at Codefresh, brought up in episode five of the DevNetwork Dev Professional Series. In this article, we follow his talk to examine the benefits of microservices, their hangups in a real-world CI/CD case study and solutions for scaling delivery as complexity and numbers increase.

    Monoliths in Space

    To get a better idea of why we need microservices, Garfield uses an analogy from space—the Apollo 13 mission. Apollo 13 was made of two ships: the lunar module and the command module. In software terms, these were essentially two giant monoliths.

    When the command module experienced an oxygen failure, its crew needed to repurpose oxygen filters from the lunar module. However, the lunar module engineers designed their oxygen filters differently, causing a major headache to reassemble and retrofit these parts.

    This analogy goes to show how monolithic-style development can create tunnel vision. When teams adopt guidelines that work only for the monolith, they are usually incompatible externally. This stifles the possibility of reusable components, thus decreasing code value and extending overall development effort.

    “Being able to reuse components and scale independently is the benefit of microservices,” said Garfield.

    Expedia’s Microservices Journey

    To see real-world microservices architecture in action, take Expedia. Previously, Expedia services had existed within monoliths, which meant much duplication. Services were detrimentally tethered, meaning if a service broke you had to fix the entire monolith.

    Garfield describes how Expedia isolated its architecture into individual microservices to represent abilities such as car search, car sorting, bookings, airline search and others. While this aided elasticity and usability, the microservices journey came with issues.

    Problems in Microservice Heaven

    Expedia ran into multiple problems within their microservices journey. Though Expedia had valid business reasons to adopt microservices, “they didn’t have a plan for how to scale their CI/CD that was realistic,” expressed Garfield.

    Foremost, as the number of microservices expanded into the hundreds and thousands, standardizing CI/CD became quite difficult. The organization was using one CI/CD pipeline per service, meaning they now had to support thousands of pipelines, each connected to an individual Git repository. A microservice may also have different pipelines for production, internal use or testing environments, leading to even more duplication.

    When you scale microservices, you also encounter a new set of roadblocks related to network and storage. This became extremely evident when Expedia realized the sheer network bandwidth and related costs from running validation and integration testing on thousands of separate CI/CD pipelines.

    “The scale of automation itself is where most people have the biggest bottlenecks,” said Garfield.

    Consolidating codebases with plugins and shared libraries became a common issue. Expedia developers experienced issues with Jenkins and were forced to programmatically or manually edit each pipeline, copy and pasting code from one to the next. In short, the flow was not easy, and differing approaches between teams led to shadow IT.

    Solutions For Scaling Microservices

    To help ease large-scale microservice environments and CI/CD pipelines, Garfield recommended taking a few approaches:

    • Use a container-based pipeline: The first principle Garfield suggested is using a container-based pipeline. If a pipeline is containerized, you can run it independently with different language versions. According to Garfield, “shared libraries are not the solution,” as they create version-specific conflicts. Using a Docker image is better than shared libraries because users can self-serve images with whatever version they want.

    There are many resources on Docker Hub to ease common CI/CD steps such as building a Docker image, git clone, running unit tests, linting projects and security scanning. Using these images can help avoid wasted development effort.

    • Consolidate to a single pipeline that operates with context: Instead of managing thousands of pipelines for all your microservices, Garfield suggested you use a single malleable pipeline for all integrations and deployments. His method involves Triggers, which carry information to direct actions.

    In this setup, Triggers carry context, or metadata, allowing a pipeline to change its behavior accordingly. These Triggers could be time-based or centered around actions like a repo Git commit, or pushing a new image. When a trigger is initiated, the trigger brings in relevant dependencies to perform an action, such as cloning a repository or cloning a codebase. Further steps can then consume these unique criteria.

    Garfield demonstrated how this is accomplished in practice within the Codefresh CI platform with native Kubernetes integrations. The platform also enables you to filter and view by certain criteria; a window into commits and changes.

    Garfield acknowledged this overall strategy does mean making microservices a bit more uniform, but perhaps the ease of deployment could outweigh the development constraints.

    • Adopt canary release testing: If an organization has hundreds or thousands of microservices, spinning up each microservice to run independent tests can quickly become cost-prohibitive. As Garfield noted, “testing early becomes less useful as infrastructure complexity arises.”

    To solve this issue, teams can adopt a canary release strategy. Canary release is a practice in which new software is first released and tested among a small subgroup of users. It’s a good way to “limit the blast radius of a change that goes wrong,” said Garfield.

    Lasting Image: Pipeline Reusability

    Adopting a single container-based CI pipeline could help resolve the expanding set of issues with large-scale microservices testing and deployment. By templatizing pipelines, many microservices could abstract complexity and reuse the same modular components. Essentially, make CI/CD reusable in the same way microservices are.

  • LogicMonitor Releases IT Downtime Detection and Mitigation Study

    LogicMonitor Releases IT Downtime Detection and Mitigation Study

    Although 99.999% availability may be IT’s ambition, it’s far from reality. In March 2019, Google’s Gmail experienced a 4.5-hour global outage. In the same month, Facebook suffered a 14-hour outage, its most massive outage to date, crippling app-accessibility worldwide.

    Downtime and low availability will likely occur to all systems eventually, especially when introducing code changes. When outages occur, it’s truly the detection systems and smart mitigation processes that separate quick rebounds from long recoveries.

    LogicMonitor has released its IT Downtime Detection and Mitigation Report, a survey of IT professionals to uncover trends and tactics impacting availability in 2020. The report surveyed over 300 IT design makers at organizations with 2,500 or more employees within the U.S., U.K., Australia and New Zealand.

    Below, we examine the LogicMonitor report’s key findings. We’ll discover, on average, what sort of projects are causing the most outages and brownouts. We’ll also see what strategies top IT teams are using to prevent, detect and mitigate disruptions.

    Which Transformation Initiatives Hurt Availability the Most?

    Ninety-six percent of organizations surveyed had experienced at least one outage in the past three years. But why? One reason LogicMonitor conducted this report was to pinpoint which digital transformation initiatives and IT trends are the leading contributors to high-profile outages and brownouts.

    When determining causation, answers revolve around novel cloud IT initiatives. Fifty-nine percent of respondents felt that mobile computing was causing more brownouts/outages. Fifty-seven percent found AI and edge computing were making outages more common. Other high-ranking reasons included digital transformation (57%) and IoT (53%).

    According to the report, “LogicMonitor’s research suggests that IT decision-makers hold IT transformation initiatives responsible for increasingly frequent outages and brownouts.”

    Though we generally view digital transformation initiatives in a positive light, they do come with caveats. The move from private to cloud infrastructure, for example, can bring unforeseen costs. Also, some authorities note a lack of talent specializing in cloud and hybrid environments. The report also suggested that accelerated cloud technologies may require time to mend before they realize positive business returns (and higher availability).

    Critical Strategies for Preventing Outages

    Another goal of the study was to discover what sort of tactics IT professionals are actively using to prevent outages.

    The study exposed many strategies that IT folks are currently undertaking. The top three tactics were performing preventative maintenance (75%), reviewing system logs (71%) and increasing the capacity of systems (71%). Other top strategies included designing redundancy into systems, and keeping an eye on customer support tickets.

    With the rise of a completely remote workforce, some IT executives do anticipate higher expenditures due to AI and cloud architecture, which could bring added pressure. However, it’s worthy to note the cloud hasn’t negatively affected all groups, or even reached all companies. According to another study conducted by Adobe and Fortune, only one in three organizations store their data in a public cloud. Of course, one could argue that in doing so, such companies substitute innovation for less breaking change.

    Another necessary aspect to keep a vigilant eye on the digital ecosystem is proactive monitoring. According to the report, 74% of teams rely on proactive monitoring to detect outages. Continuous monitoring has been a philosophy trumpeted time and time again by DevOps professionals to enable a better release frequency and a window to detrimental interruptions.

    Careful analysis ahead of time, active monitoring systems to spot problems and continuously reviewing system logs were the most important tactics found being applied by IT leaders to mitigate found outages and brownouts.

    Best Practices: Prevent, Detect, Mitigate

    In terms of takeaways (other than the ultimate LogicMonitor product sell), the IT Downtime Detection and Mitigation Report does reveal some interesting trends on what IT leaders view to be leading causes of system outages. It will be interesting to see how this evolves and what technologies mature (or remain headaches) into the future.

    The report leaves IT professionals with some common, albeit helpful, advice to consider going forward:

    • Actively monitor IT systems.
    • Optimize IT systems with forecasting.
    • Prepare for tomorrow’s IT norms today.
    • Use intelligent monitoring.
    • Design redundancy into your systems.