devopsy.kinsta.cloud

Tag: Big DevOps

  • Top Misconceptions About Low-Code Development

    Top Misconceptions About Low-Code Development

    Accelerating the pace of development has become one of the biggest goals in DevOps. After all, having teams speed the creation and modification of applications is supposed to be one of the primary advantages of DevOps pipelines. Yet, far too many DevOps teams run into speed bumps that can derail the process. For some, turning to alternative methods to generate and modify code can slay the beast of project deceleration, and that is where low-code platforms come into play.

    However, the waters are muddied by misconceptions about what low-code is and what it isn’t. Here, three industry experts share their own observations about these common misconceptions.

    Low-Code is Only for Citizen Developers

    “People often confuse low-code with no-code platforms,” said Richard Rabins, CEO, Alpha Software Corporation. “No-code platforms, which are driven by visual modeling and user interface builders, are aimed at citizen developers with little or no coding experience to quickly build applications.” Rabins makes some good points; no-code environments are designed to put the power of application development into the hands of a citizen developer, meaning those no-code platforms are optimized for simple workflows and not for teams. On the other hand, low-code platforms can integrate with deployment platforms, which helps expedite delivery while also enforcing consistency.

    Low-Code Makes Collaboration and Reusability Difficult

    “Over time, many developers have come to believe that low-code platforms were built for a single programmer working on a waterfall project,” said Deepak Anupalli, co-founder and VP of Engineering at WaveMaker, Inc. “Today, low-code platforms, like WaveMaker, offer development environments that integrate with code management tools, as well as APIs, to support the sharing of code and fostering team collaboration.” Anupalli’s point is that the majority of low-code platforms incorporate workflows that support team activities. What’s more, those platforms support scale-up, reuse of code and the ability to work within pipelines.

    Low-Code Prevents Custom Development

    “From the beginning, low-code was all about building applications with little or no code needed, creating the perception that low-code platforms did not lend themselves well to customization,” said Rabins. “However, nothing could be further from the truth. Developers are able to expand the functionality of low-code projects as the need arises. They can insert custom code, call APIs, integrate with other platforms, and so on.” Rabins points out that low-code doesn’t mean no-code, simply that low-code can generate code that can be modified and adapted as needed, supporting pipelines that deliver fully customizable applications.

    Low-Code Platforms are Only a Trend

    Many seem to think that low-code platforms are just a trend that will ultimately fade away as other technologies come to light. However, according to Business Wire, the low-code market will grow 44.4% by 2022 to reach $27.23 billion. Anupalli added that WaveMaker has experienced year-over-year growth since the company was founded.

    Leaders in the market today include Visual LANSA, GeneXus, Appian, Mendix, OutSystems, WaveMaker and Alpha Software. 

    Low-Code Solutions are Proprietary

    One of the leading assumptions about low code platforms is that they all use some type of proprietary programming language. That may be true for a few platforms, but many embrace open source ideologies and use common languages, such as Java, PHP, and C#. Take, for example, the RISE Editor, which enables users to output code based on models in a number of different languages. RISE is not alone in the industry; several other platforms embrace either open source or can create easily accessible code. VisionX and WaveMaker create in Java, allowing generated code to be edited with other Java IDEs.

    Low-code development platforms (LCDPs) have come a long way since the term was first coined by Forrester Research back in 2014. And yet, these numerous misconceptions remain, which may have slowed the adoption of LCDP in enterprises using DevOps pipelines. Dispelling these assumptions goes a long way towards helping application developers realize the benefits that LCDP can offer. 

      

     

  • Big DevOps: Too Slow to Win?

    Big DevOps: Too Slow to Win?

    There’s DevOps. And then there’s Big DevOps.

    DevOps is a set of disciplines that accelerates time-to-value for digital deliverables. It is being embraced by all kinds of companies, from pure-play digital market disrupters to mainstream corporates trying to maintain competitive parity with their mobile apps.

    Big DevOps is something else entirely. Big DevOps resembles mainstream DevOps, because it’s a process by which companies bring code to market. But if you’re a game developer or large bank, your code bases are massive—and your software life cycle requires you to distribute those massive code bases across globally dispersed dev and test teams.

    Distribution of massive code bases on a global scale creates time-to-value challenges that are totally foreign to programmers checking bite-sized blocks of work in and out of GitHub. These scale-related distribution challenges chronically delay DevOps workflows—impeding your company’s digital agility and seriously undermining your ability to compete in today’s time-gated markets.

    So you must overcome your Big DevOps code base distribution problem.

    Choking on Code

    The main culprit responsible for the slowness of Big DevOps is the network. It just takes too much time to push a massive code base through the relatively narrow pipe of an enterprise network. Even if you spend lots of money on bandwidth and network acceleration, the ratio between your bits of code and your bits-per-second of network is untenable. Every distribution of every large code artifact gets delayed. Over and over, day in and day out.

    Those days add up. And when you pile days lost due to network-related delays on top of the other delays that plague large, complex software projects, you wind up persistently late to market.

    And cloud alone can’t help you. Globally dispersed teams can’t work on a massive code base in the cloud. They have to work with it locally. So you have two problems. First, all your teams all over the world have to keep downloading and uploading massive files. Second, you have to make sure everything everybody does everywhere stays synced.

    That’s why you need a much better way to globally distribute massive code bases.

    Work Locally, Dedupe Globally

    That better way is a hybrid hub-and-spoke model that lets you maintain a “gold copy” of your code base in the cloud—while giving everyone everywhere a local copy that is continuously updated with any changes to the current build. This approach eliminates network-related delays while ensuring conflict-free collaboration across geographically dispersed teams.

    It’s a simple approach that works. In fact, it’s been used by CAD/CAM teams for years to address a very similar file distribution problem.

    Hybrid cloud hub-and-spoke also saves money—because you can spend less on your network and your local storage infrastructure.

    Cost, however, is not the existential issue facing Big DevOps. Time is. Companies that are slow to market with their digital deliverables can’t win against fast ones. So if your company is big—and if you’re doing Big DevOps—you have to solve your time-to-market problem. The realities of digital competition demand it.

    — Barry Phillips