devopsy.kinsta.cloud

Tag: SaaS

  • Checkly Adds Monitoring-as-Code to Testing Platform

    Checkly Adds Monitoring-as-Code to Testing Platform

    Checkly this week added a monitoring-as-code (MaC) workflow capability to its software-as-a-service (SaaS) platform that is used to create synthetic tests for applications.

    The Checkly platform spins up browsers to test and can now monitor how applications are performing at both the user interface and application programming interface (API) level. That capability, currently available in beta, is enabled via a command line interface (CLI) for accessing an instance of TypeScript to invoke MaC workflows.

    Checkly CEO Hannes Lenke said that integrated approach enables application development teams to observe applications in as little as 60 seconds without instrumenting them with agent software.

    As part of that effort, Checkly also made generally available Playwright Test, a testing platform for web applications that spins up modern browsers on demand in addition to updating its public dashboards and adding an analytics API.

    Finally, the Checkly SaaS platform has passed a SOC 2 Type II security audit.

    Lenke said the overall goal is to make it simpler for developers to discover and remediate issues as they assume more responsibility for the ongoing management of applications.

    It’s not clear whether developers are taking over responsibility for testing and monitoring applications, but as more responsibility for applications shifts left, organizations are looking to give developers the tools they will require to succeed. That doesn’t mean IT operations teams won’t need to continue to monitor IT environments, but developers do need integrated tools that give them enough meaningful context to address them as they write code. Synthetic testing tools also enable developers to address many routine issues long before they might be discovered by a dedicated testing team that should be focused on ensuring the overall quality of the user experience.

    Regardless of the approach to testing and monitoring, Lenke noted that the silos that make up the software development life cycle are becoming more tightly integrated in modern application development environments. The primary objective is to make it possible for organizations to accelerate application development without compromising quality, he added.

    Of course, the more testing that occurs early in the application development process, the fewer issues a DevOps team should encounter after an application has been deployed in a production environment. The issue is that, historically, much of that testing occurs late in the application development process. Each time a project falls behind schedule, there is naturally a greater temptation to reduce the amount of time spent on testing to ensure the on-time delivery of an application. Providing developers with tools for testing and monitoring applications as they are being built should ensure that the proper level of testing is occurring before an application is deployed.

    There will, however, never be a perfect application. Over time, DevOps teams will discover that every application is impacted by drift to varying degrees as updates are made and the underlying infrastructure is upgraded. The most critical issue is reducing the number of potential issues overworked DevOps teams may need to address later on by ensuring the code being deployed is of the highest quality possible.

  • What’s Ahead for the Future of Data Streaming?

    What’s Ahead for the Future of Data Streaming?

    Data is everywhere. It’s being produced by almost everyone and everything around us. For businesses to be competitive, they need to build resilient, scalable systems that can efficiently tap into and react to this ever-increasing volume of data. Companies are meeting this need by moving to real-time data streaming to develop new solutions and improve their businesses and customer experience.

    This category of data streaming has been growing. And, driven by the rise of real-time digital experiences like ride-sharing, fraud detection, inventory management and more, the growth has accelerated.

    So what’s next for data streaming?

    Data as a Product Grows in Popularity

    The concept of data as a product will become more mainstream. Across many industries, data streaming is becoming central to how businesses operate and disseminate information within their companies. However, there is still a need for broader education about key data principles and best practices, like those outlined through data mesh.

    Data as a product is foundational to rethinking how data produced in one part of a business can be reliably used in another. Data products with formalized ownership and responsibilities, combined with a platform for discoverability and accessibility, result in significantly fewer barriers and a much easier data access experience for all. Schemas, the Kafka API and maturing specification standards like ASyncAPI can be a part of this evolution.

    As more folks embrace this mindset, I expect to see companies shift from using ad-hoc data pipelines to ones based on data products, driving a centralized system that can power both better analytical insights and operational execution.

    Growth of Self-Service Solutions

    With the rise of cloud-based offerings, I expect to see more companies offering more accessible, pay-as-you-go, self-service solutions. We’ve already seen this shift over the past few years; cloud-based offerings are making it easier for companies to try out a data product based on their usage (or lack thereof). Given the current market conditions, these offerings will be more appealing to organizations that aren’t ready to sign a multi-year contract for a product offering or focus solely on a single technology.

    Increase in Cloud Migrations and the Continued Rise of SaaS

    Cloud is here to stay. We’ve proven that it works, that it’s safe and secure, and for many folks, it just makes sense. This should come as no surprise to anyone, but expect the trend of cloud migrations to continue.

    In the context of Apache Kafka, building out a Kafka-based data streaming solution used to mean hosting and managing your own Kafka cluster. If you’ve ever been in that position, you know that usually means more DevOps work and less focus on building applications to get the most out of your data. Not only do cloud-based Kafka offerings eliminate much of the DevOps headaches that come with a Kafka cluster, but they also make it much easier and faster to hit the ground running and begin streaming your data.

    I’m personally excited by what the cloud and SaaS can do to make Kafka and data streaming more accessible. In my visits to developers and companies around the globe, I see this enthusiasm shared by so many. Entire geographic regions and industries are taking the opportunity to move to the cloud and dive headfirst into data streaming.

    KRaft Leads to Rise in Kafka Adoption

    As of Apache Kafka 3.3, the KRaft consensus protocol has replaced Zookeeper and is production-ready. Cluster metadata can now be maintained and managed from within the cluster, meaning there’s one less thing to worry about when deploying Kafka instances.

    While there are many options for cloud-based Kafka-as-a-Service, improvements such as KRaft in open source Kafka make self-hosting even easier. This, along with the work done to make it simpler to run managed Kafka services on local machines and test environments, means that Kafka no longer has to be synonymous with complexity. With the difficulty of managing and maintaining a Kafka instance no longer preventing folks from making use of data streaming, I predict that the adoption of Kafka will increase even more.

    Data streaming will continue to mature as a transformational technology for companies of all sizes, serving as a critical infrastructure that most organizations will need to run their business.

    If you haven’t yet explored what data streaming has to offer you, maybe this will be your year to check it out!

  • We’re Doing More Less Development

    We’re Doing More Less Development

    My roots are in software development. I’ve written tax software, SmartGrid firmware and servers, enterprise integration code for many developed and purchased servers, mapping software, cell phone firmware—the list goes on. The point is development is in my blood. When I look at something that impacts software development, I look at it through a practitioner’s lens as much as an analyst’s. And there is a lot of change going on in the realm of software development.

    For a very long time, there have been options out there that reduce the amount of software we develop. And those options are often popular. There was a time where the most common phrase in enterprise IT was “Develop core systems, purchase support systems,” and the message sank in enough that we don’t need to say it anymore. There was a time when enterprises cobbled together systems as essential as email–some developing their own systems, but most working hard to integrate available offerings. We have completely flipped that equation, and now almost no one would consider spending significant IT resources on email. Not on development, not on integration. There are of course corner cases that do have to–our industry could be defined as a collection of sharp-corner cases we haven’t yet smoothed out–but few, if any of those reading this blog have had to worry about those corners. So, change number one: Purchasing IT solutions is massively successful at reducing our time. From CRM to email to security, we’re using far more tools written by others.

    There have also been code-generation tools forever. While the most well-known ones have historically been UI-focused, 4GLs generally tried to address development with less code. Again, time, failures and iterations have given us useful code-reduction techniques. From pre-formatted ‘if’ statements that we just plug in variables to API generation through (sometimes AI-powered) initial program generation engines that give us code to start a project. The requirements for writing code are less per-project.

    And the big one: Open source. There are entire software markets for which it isn’t worth developing solutions because there are good open source solutions on the market. If it is popular but even vendors cannot afford to make solutions because everyone is using the OSS solution—well, that reduces the amount of code developed. There are several companies whose entire business model is simply offering enterprises service and support on OSS. No development required, even for the “vendor.” Large portions of any given application we develop these days are based on open source that we include to solve one piece of the problem. We’ve had some spectacular hacks and failures based upon that model, but it is undeniably an enabler for more solutions.

    With all of these (and arguably more–like API-first and API standardization) reducing the amount of code we’re developing, you would think developers would be less busy, right?

    DevOps and Agile streamlined our development and shortened delivery timelines for subsets of a given project, but haven’t—and weren’t designed to—reduce the amount of software developed. Indeed, quite the opposite. With faster iterations, more could be tried out.

    But it is wrong to think there is less development effort. There are several reasons for this, but I’m going to focus on the big one. People invested in the company—business leaders, etc—have always had a massive pent-up desire to improve software to increase efficiency, competitiveness, etc. And IT was the bottleneck. Agile/DevOps are by no means perfect, but they offered a pressure release valve for that pent-up demand. And we’ve been at it long enough to know that rapid iterations in response to those demands inspire more new ideas, creating another iteration… So it will be unlikely to stop. Indeed, we all know what technical debt is, but there seems to be a disconnect between knowing intuitively that more code means more debt in the form of maintenance overhead. So developers are doing more because the organization has good ideas that need implementation, even though we have plenty of tools to reduce development effort. Some organizations have reduced developer headcount, but not many. And that might slow, but that’s unlikely. In the coming highly competitive environment, more features and solutions will be desired, not less.

    And you’ll be there, continuing to rock it. Pay attention to ways you can further reduce code effort. This is a long-term process, but the goal should be to reduce the growth rate in staff time. It is unlikely to go down overall–because maintenance overhead plus new projects is a constantly growing number–but slowing growth helps developers and working managers stay sane and take the time to find good hires.

    And just keep doing more less development.

  • Why SaaS Vendors Need to Give Back to Open Source

    Why SaaS Vendors Need to Give Back to Open Source

    There aren’t many tech organizations that don’t leverage open source technology. Companies that refuse to import software will rely on a freely available library tool or codebase. Open source is one of the largest and most powerful mechanisms of software propagation. However, open source is in danger.

    The Two Sides of Open Source Development

    In recent years, the ubiquity and dominance of open source tooling have led companies to adopt them en masse. Products like Elasticsearch, Spring and Akka are incredibly popular as open source, freely available tools. But unfortunately, often only one-half of the open source philosophy is being honored.

    The Open Source Philosophy

    What does that mean? Well, open source depends on two things. Customers use the software and those same consumers contribute to the codebase. It’s a feedback loop of like-minded individuals who have a shared interest in building and using an outstanding product and are happy to donate their time to realize their collective goals. This agreement has driven some of the most exciting software achievements of the past two decades.

    Alas, while it became prevalent to use open source software, the popularity of contributions did not scale equally. Suddenly, small teams of dedicated developers were inundated with demands from huge enterprises that equated “open source” with “free.” This caused the owners of open source projects, like Elasticsearch, MongoDB and Akka, to reevaluate their position and change to the increasingly prevalent source available license.

    Growing Risk to the Open Source Community

    If users contribute to the codebases they leverage, then those codebases can thrive and no one needs to worry about subscription fees or fines. Moreover, users can maintain the certainty that they are not doing anything illegal when they depend on a piece of software. Without contributions from the engineering community, an open source project’s commercial and practical basis quickly disintegrates.

    So Why Should SaaS Vendors Give Back?

    SaaS solutions inhabit a particular corner of the market, assisting companies in solving a cross-cutting problem. For example, observability. This is an important detail because many open source tools also operate in this arena. This is exemplified by the fact that it’s common for SaaS vendors to regularly compete against an open source, homegrown alternative. Many SaaS solutions actually base their core infrastructure on the same open source software.

    This means that SaaS providers are often in direct competition with the open source solutions they leverage to build their product(s).

    SaaS Vendors Depend on Open Source Software

    The communities that support vital pieces of open source software, like Apache Kafka or OpenDistro, are helping to unlock innovation in enterprises worldwide. The continued pace of this innovation is inextricably linked to the continued growth and development of the open source tooling on which it depends.

    The only sensible course of action is for SaaS vendors to make every effort possible to contribute back to the open source space. They do not need to give up their unique features, nor do they need to release their proprietary software, but the simple act of maintaining patches, improving performance, increasing compatibility and even correcting poor documentation—all of this is a contribution that will benefit the entire SaaS ecosystem.

    Those Contributions Will Breed Specialization

    A big challenge of using open source software is finding engineers that understand how it works. The plug-and-play nature of many tools means that users never need to dive into the details of a library or application. This, however, comes at a cost. Users often don’t know why the software breaks or behaves unpredictably.

    If a SaaS vendor begins to contribute back into the core of the open source tools on which they depend, not only are they benefiting their product and the open source community, but they’re also seeding specialist knowledge in their teams. This specialist knowledge means they can utilize open source features in new and exciting ways, giving them insights and advantages over their competitors.

    Open Source Contributions Make Commercial Sense

    The SaaS community thrives when open source tooling works smoothly. Conversely, if fundamental open source tools like Kafka or OpenDistro begin to falter, then the success of the SaaS community is also at risk. They are highly interdependent. This means a contribution back to core open source tools is a contribution to the stability of SaaS products. Moreover, growing specialist skills within engineering teams means that when it comes time to leverage a new open-source feature, your developers may have skills and insights that other companies won’t have. This is a clear commercial advantage, and all for the cost of doing the right thing, and keeping the dream of free, open source software alive.

  • Nobl9 Adds Free Tier to SaaS Platform for Managing SLOs

    Nobl9 Adds Free Tier to SaaS Platform for Managing SLOs

    Nobl9 this week announced it is making available a perpetual free tier of its software-as-a-service (SaaS) platform for managing service level objectives (SLOs).

    The free tier was announced at the AWS re:Invent 2022 conference and the company also revamped its pricing. Nobl9 Teams Edition (formerly Nobl9 Hydrogen) now includes 50 SLOs, up from 25, for $850/month. Nobl9 Enterprise Edition also has doubled the included SLOs from 75 to 150.

    Finally, Nobl9 also launched SLOcademy to help educate IT teams on how best to create and manage SLOs.

    The Nobl9 platform simplifies the creation and tracking of SLOs using metrics and observability data collected from more than 24 widely used DevOps tools including Prometheus as well as services provided by Datadog, New Relic, Dynatrace, Google, Amazon Web Services (AWS) and Splunk.

    Kit Merker, chief growth officer for Nobl9, said the company’s platform collects signals from logs, metrics and traces to define what normal should look like for any given service. The free tier of the platform has some limitations, but it does provide access to the full-featured platform to enable IT teams to get started managing SLOs.

    SLOs, of course, are not a new idea. They have been used as a metric to track the performance of IT services for decades. It’s not clear whether reliance on SLOs has waned over the years or if application environments simply became too complex to track meaningful metrics. However, as applications are increasingly viewed as services, it’s now only a matter of time before SLOs become more widely adopted across a modern application environment. The challenge, of course, is that defining an SLO is a lot easier than maintaining it—especially within today’s highly dynamic cloud-native application environments where services with lots of dependencies tend to come, change and go unexpectedly.

    Nobl9 is making a case for an SLO-as-code approach that makes it simpler to track service levels. A recent survey of more than 300 IT managers and executives conducted by Dimensional Research on behalf of Nobl9 found only 29% of respondents had no plans to implement SLOs. A full 94% of respondents that have or plan to implement SLOs intend to map them directly to business operations, with 91% reporting that they expect that effort to improve decision-making. More than 80% also said their organizations are planning to increase the use of SLOs, with 87% indicating SLOs should improve overall microservices performance.

    The challenge is that most organizations have limited visibility into their IT environments. The survey, for example, found less than half of respondents (46%) had visibility into all their IT environments. Only 45% and 35% claim to have visibility into containers and microservices, respectively. More than three-quarters (78%) said hybrid clouds make observability more difficult. Ironically, 45% of companies reported they already employed 11 or more observability and monitoring tools. On the plus side, 31% have hired site reliability engineers (SREs) while nearly half (46%) planned to create that role.

    It may be a while before most IT teams are organized around the concept of applications as services but as the management of IT continues to evolve it’s now just a matter of time before that approach becomes more the rule than the exception.

  • GitLab Unfurls Dedicated SaaS Edition in the Cloud

    GitLab Unfurls Dedicated SaaS Edition in the Cloud

    GitLab today made available to a limited number of customers a single-tenant version of the software-as-a-service (SaaS) edition of its continuous integration/continuous delivery (CI/CD) platform.

    David DeSanto, vice president of product at GitLab, said the GitLab Dedicated option provides all the benefits of a cloud platform without running afoul of any potential compliance issues.

    Designed to be deployed on a cloud platform selected by the customer, DeSanto said the single-tenant edition of the platform makes sure that all the data stored in the cloud is isolated. In addition, the access to GitLab Dedicated is provided via a private network connection, he added.

    Initially, GitLab Dedicated is being made available on the Amazon Web Services (AWS) cloud with support for other cloud platforms planned for 2023 once it becomes generally available.

    GitLab is, in effect, trying to strike a balance between a lower-cost multitenant edition of the platform or, alternatively, requiring organizations to deploy an on-premises edition of the platform themselves, DeSanto said.

    In general, GitLab expects this latest version of the platform to appeal most to organizations that operate in highly regulated industries. However, the number of organizations looking to isolate their data in a private cloud to better protect their software supply chains is expanding, he noted.

    In the wake of a series of high-profile breaches and vulnerability disclosures, the number of organizations that are reviewing their software supply chains has increased. Less clear is the degree to which organizations will look to lock down their existing CI/CD platform versus replacing it with a more secure modern alternative that can be more easily accessed via the cloud.

    The challenge, of course, is replacing a CI/CD environment is not trivial, so organizations will need to consider the time and effort made over the years to customize their CI/CD environment. In some instances, that customization provides a meaningful competitive advantage. In other cases, however, the weight of maintaining all those customizations has become more troublesome than it’s worth.

    Each individual organization will need to decide to what degree they will want to manage the DevOps platforms used to construct applications. More organizations are deciding they prefer to devote as much of their resources as possible to writing code instead of managing the underlying CI/CD platform used to create their applications, said DeSanto.

    Regardless of approach, the number of organizations adopting DevOps best practices to build and deploy applications faster continues to increase. A CI/CD platform accessed via the cloud lowers the barrier to entry for smaller organizations that typically don’t have the skills and resources required to manage DevOps platforms.

    In the meantime, SaaS-based approaches should significantly increase the number of applications being constructed using DevOps workflows. The level of DevOps adoption will naturally vary by organization. However, the total number of custom applications being used to drive, for example, digital business transformation initiatives should considerably expand in the months and years ahead as more applications are built and deployed at incredible speed.

  • Agile Pricing, Agile Uptake

    Agile Pricing, Agile Uptake

    It is pretty amusing, the number of software vendors that are selling us tools to work in our Agile and/or DevOps infrastructure but are not at all agile in their sales cycle implementation.

    Top-line vendor hint: If you have a page titled “pricing” and there are no prices on it, you’re doin’ it wrong.

    Let’s be serious, here. I should not have to drop everything, call you and go through a whole lengthy, involved process before I can implement a product that you claim makes my development or deployment life cycle more agile.

    Beyond the ‘there is no price on the pricing page’ issue, there are the vendors that go to great lengths to keep us from knowing what they cost. Some fail because they have public cloud images with pricing on them, but some even get around that by including “bring your own license” and selling the instance cheaply.

    In almost every case, competitor pricing is available, is simple and TCO can be calculated. If yours can’t, you are not winning mindshare.

    I probably recounted here that, once, a big-name database vendor tried to charge us insane amounts using the “You have to talk to us” model. I escalated to my VP, who told the salesperson, “I am not buying your Lamborghini,” and we then paid to have the product ported to a competing database with open and easy pricing and minimized use of the product on the offending DB. The moral of the story is, “Keep it simple and make it worthwhile.” We would have paid millions more than we did (which was already a lot) for that project. The vendor got nothing by making convoluted pricing schemes that allowed them to say every endpoint was a user and insisting we should pay the full license price for them.

    Top line vendor hint number two: We’re professionals. We install, configure and manage a variety of systems every day. If your system requires services to get up and running, you should consider why that is.

    We are not looking to spend months scheduling installation and configuration because you, the vendor, think services are a mandatory part of implementation. We can deploy entire infrastructures without requiring assistance; what is wrong with your product that we cannot deploy it in the same manner?

    In general, organizations are willing to pay well for a product that does the job. Hidden pricing, confusing pricing and mandatory services to get the system running all make it harder for an organization to evaluate the value of the product. Saying “Start Free Trial” without explaining pricing is perhaps the funniest vendor move ever. Of course we want to know what we might be getting into before we sign up for that free trial!

    Sell us good tools at a clear and reasonable price. We’ll buy them. Because we have a job to do and we want the tools to do it. We don’t want to drop everything to find out what it will cost us to do it and we don’t want to be forced to buy services to get it running.

  • Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod Looks to Drive Application Development Into the Cloud

    Gitpod today revealed it will add an application programming interface (API) to make cloud development environments (CDEs) more extensible. Gitpod also said Johannes Landgraf assumed the role of single CEO for Gitpod, as the previous co-CEO, Sven Efftinge, becomes the company’s first technical fellow.

    Fresh from raising an additional $25 million in funding, Gitpod’s Landgraf said that API will make it easier to build plug-ins for CDEs. In time, Landgraf said, CDEs will become as accessible as any development environment running on a local desktop.

    Software engineers typically waste five hours a week maintaining application environments, noted Landgraf. Via an open source development platform, Gitpod automates the provisioning of secure workspaces in the cloud that provide the added benefit of making it easier for multiple developers to collaborate, he added.

    Capabilities added to the GitPod product roadmap include dramatically faster startup times, improved resiliency and a Gitpod Cloud offering for larger companies as well as a preview environment and workflows that foster collaboration. Gitpod also announced it passed a SOC2 Type II security audit.

    Today, the Gitpod platform is being used by more than 750,000 developers at organizations such as Shopify, Stripe and Slack, noted Landgraf.

    One of the longstanding issues that has always been problematic when building software is that code that runs on a local desktop doesn’t always work when deployed in a production environment. The Gitpod API will make it simpler to spin up various platforms and tools whenever a developer accesses a CDE. The goal is to make it possible to more closely replicate the production environments on which developers will ultimately deploy their applications, noted Landgraf.

    In addition, a CDE should reduce the amount of data that developers routinely move between laptops and cloud computing environments as they build more complex applications, he added.

    In the wake of the economic downturn, there is a lot more focus on developer productivity these days, especially as organizations look to accelerate their of digital business transformations. DevOps teams are also keen to find ways to centrally manage developer experience at a time when many of those developers continue to work from home, said Landgraf.

    It’s not clear to what degree CDE will replace integrated development environments (IDEs) running on a local machine, but all the major cloud service providers are encouraging developers to build applications in the cloud where their applications will run. The challenge is that many of those offerings tend to lock developers into a specific cloud platform, noted Landgraf. Most developers today are building applications that need to be deployed across multiple clouds, he added.

    One way or another, software development is increasingly shifting to the cloud. Most organizations will likely try to find a balance between the amount of code developed on a local machine that developers can just fire up when the mood strikes and the amount of code developed in the cloud. The most immediate challenge is to make sure the CDE experience is every bit as good as the existing local IDE.

  • Know What You Want and Need

    Know What You Want and Need

    Over the years, what we purchase from vendors has changed significantly. It used to be that IT would define a need, go out and find a bit of software to solve it, install and configure the software and, in most cases, spend the majority of time on the project getting it to work correctly in their environment. Those days are largely gone. First, we started buying appliances for some functionality, then we started using MSPs for some or all functionality, then some vendors wanted to deliver in a VM where they could make configuration much easier by controlling the environment. That was the first step to virtualizing purchases. Then we started looking at infrastructure-as-a-service (IaaS), then SaaS, then some vendors offered PaaS … Currently, all of the cool vendors are offering containers—which are an improvement over VMs, and offer a virtual appliance that is quick to get running and tested to do what it was purchased for. Or at least tested to do what it was sold for. We’ve all got stories about what we did with these purchases that were “off label”—things that a product really wasn’t designed for. Along the way, we also introduced open source vendors; a bit of an oxymoron that really described service orgs that base their product on an open source project. Some far more successfully than others.

    And all of that, dear reader, is why we are here. Before purchasing, there is a lot more to find out than there used to be. What, actually, is the product this software vendor is selling? In the end, IT is looking to solve a problem. Most of the time, whether that problem is solved by SaaS, local install or cloud instance is less important than how well the problem is solved. But implementation—and licensing—are important to an organization if not immediately, then over the long term.

    When purchasing an open source “product”, you’re … actually not. You are getting the product and purchasing support. Since open source can be hacked to run just about anywhere given enough time, more than one OSS vendor has pretended that makes them superior to commercial products targeted at a specific platform. That is blatantly untrue—unless the OSS vendor is supporting the product anywhere and everywhere which, of course, they are not. I can port the OSS project MyFunApp to any platform I want without paying for support that won’t do a thing for me when I get it up and running on OS/2 (as an extreme non-existent example).

    SaaS has more issues when it comes to TCO. While pay-as-you-grow is cool and all, locking in a monthly payment forever is a big step and should be considered. And at an enterprise, “forever” needs to be considered realistically. Implement a particular SaaS CRM and you are unlikely to move to another, even if you claim that you will in a heartbeat. It’s work. A lot of work. It is definitely possible, but for most organizations, unlikely. So know what you are getting into. And while you are evaluating, don’t forget to consider variable charges, which most SaaS products have. Make certain you understand what the actual monthly costs are likely to be. IaaS suffers this same variability problem, as many of us have learned.

    Containers are a very sweet solution to appliance-like functionality—drop a container into your Kubernetes flavor of choice and move along. The problem here is a combination of proliferation—how many are required? One per pod can get expensive over time, for example. Those resources aren’t free, no matter the platform. The other issue is updates. Automatic updates are the norm for container instance-delivered products. From a security perspective, you should have questions. Updating things in your network should probably require your approval.

    I’m not suggesting that one delivery method is better than others here; I’m simply suggesting that we all need to be more deliberate about those choices than we’ve needed to be in the past. Knowing not just SLAs but the cost and support implications of every choice is important both today and down the road.

    Keep kicking it, and keep picking the solutions that best solve the organization’s problems. Just be aware that sometimes, the issues a delivery method introduces undermine the effectiveness of the solution.

  • Making App Dev More Efficient

    Making App Dev More Efficient

    Applications of all kinds are continually popping up across various industries to help improve consumer customer experiences, provide entertainment, make certain tedious or error-prone tasks easier for workers and to help businesses improve their operations overall. In fact, there are over 5.4 million applications available across the Apple App and Google Play stores as of this year.

    As more and more individuals and organizations turn to applications for various experiences and to drive enterprise efficiencies, we need to take stock of the process we deploy in application development.

    The Inefficiencies of Application Development

    Today, it is estimated that there are more than 26 million software developers worldwide. Each of these developers brings a unique combination of creativity and technology acumen to the organizations they work for and the applications they create. However, the current application development process in many enterprises is riddled with inefficiencies that often require these talented developers to focus on tedious, mundane, non-innovation-related tasks. 

    Technical Debt: Renowned programmer Ward Cunningham first introduced the concept of technical debt in 1992, stating, “Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.” What many didn’t realize at the time was that technical debt would grow to be a major issue in software and application development years later. Recently, a new Scandinavian study found that developers dedicate 23% of their time, on average, to addressing technical debt. While this statistic alone should be alarming to enterprises—given their development teams are spending a quarter of their time on an issue that could have been avoided had a different approach been taken—the study also found that developers often have to introduce new technical debt in the process. 

    Maintenance: As with all technological equipment, applications require routine maintenance to ensure they remain working for the end user, provide ongoing value and are secure. However, unlike a car or kitchen appliance, applications see far more frequent updates from operating systems (OSes), cloud or hardware providers that need to be addressed by development teams. According to research from Stripe, developers spend more than 17 hours per week on maintenance issues like debugging or refactoring. For instance, take a look at Apple. From the time iOS 15 was released in June 2021 as a beta, there were more than a dozen updates made to the OS until early September 2022. That means that every single time the updates were released, developers had to spend time ensuring their applications were working correctly, were bug-free or complied with new security measures. When you add this to the fact that the average enterprise app has 110 third-party integrations, that is an extreme amount of maintenance.  

    The Reinvention of the Wheel: Of all the applications available today, many of them consist of the same foundational features and functionality—login, chat, social sharing, payments and more. What’s astonishing about this is that developers are frequently recreating each of these common features and functionalities from scratch every time they develop a new application. 

    It is clear that these tasks are highly inefficient, and it begs the question, “What can be done to address these inefficiencies?” 

    Prioritizing Innovation 

    It is not enough to just introduce some sort of technology in the hopes that it makes application development more efficient. It also requires an overall mindset change by enterprises. Yes, it is still of the utmost importance to get applications to market quickly and keep up with the pace of competition; however, innovation doesn’t have to be sacrificed to do so. 

    Innovation must be the key driver for enterprises and their development teams. Providing unique value and experiences to end users will truly set enterprises and their applications apart from the competition. But, the reality is that nearly 80% of technology leaders from around the world believe basic application maintenance and support are the biggest barriers to innovation. 

    Enterprises must be able to balance innovation, time-to-market and development processes that are free of technical debt and outrageous maintenance support. 

    Making Application Development More Efficient

    One way in which enterprises can balance innovation, commercialization, and development is through an emerging approach to application development known as features-as-a-service (FaaS). 

    A FaaS approach to application development enables enterprises to implement an agile and accelerated engineering process—similar to that of low-code/no-code without the constraints often seen with those vendors and their functionality today—without sacrificing quality, code or time. More specifically, it combines pre-coded “commodity” features with continuous and automatic updates that empower development teams to spend their time and creative minds on innovation. In most cases, this approach can help enterprises bring applications to market within weeks instead of months and limits the headaches on the backend for development teams down the line. 

    As enterprises work through the fourth quarter of this year, I implore them to reconsider their development process at a fundamental level and bring innovation to the forefront before the beginning of 2023. Time and resources are of the essence, and something must be done now to address the inefficiencies of application development.