Category: DevOps in the Cloud

  • AWS Looks to Meld MLOps and DevOps

    AWS Looks to Meld MLOps and DevOps

    The rate at which machine learning operations (MLOps) and DevOps best practices are converging is poised for rapid acceleration in 2021. At the recent online AWS re:Invent conference, Amazon Web Services (AWS) announced it is adding a bevy of capabilities to Amazon SageMaker, a managed MLOps service, that includes a continuous integration/continuous delivery (CI/CD) service for MLOps it is calling Amazon SageMaker Pipelines.

    Amazon SageMaker Pipelines enables developers to define a machine learning workflow that encompasses everything from loading data to training configuration; algorithm set up and debugging algorithms. Rather than having to acquire and deploy a standalone CI/CD platform for building artificial intelligence (AI) models, AWS is making the case for using a managed service that enables developers to manage workflows from within the Amazon SageMaker Studio tools it already provides for building AI models.

    Workflows can be shared and reused between teams to either re-create a model or can serve as a launch point from which to create another AI model.

    Amazon SageMaker Pipelines also logs each event in Amazon SageMaker Experiments, which enables IT teams to organize and track machine learning experiments and versions of AI models. In addition, a Deep Profiling for Amazon SageMaker Debugger now makes it possible for developers to more quickly train AI models by automatically monitoring system resource utilization and generating alerts whenever bottlenecks are detected.

    AWS has also added a Distributed Training capability to Amazon SageMaker that it claims makes it possible to train large, complex deep learning models up to two times faster than current AWS approaches by enabling data and AI parallelism across its cloud services.

    The cloud services provider has also added an Amazon SageMaker Edge Manager service that enables developers to optimize, secure, monitor and maintain machine learning models deployed on fleets of edge computing devices. The Amazon SageMaker JumpStart service enables developers to search for AI models, algorithms and sample notebooks.

    Finally, AWS has added additional data preparation tools that come pre-configured with support of AWS and third-party data sources, a repository for storing AI models, a preview of additional tools for automatically matching AI models to data sources such as the Amazon RedShift data lake, the ability to match an AI model to a graph database and a tool that detects bias within AI models.

    Bratin Saha, vice president and general manager for machine learning services at AWS, said as usage of AI models increases, the scope of these initiatives naturally lends itself more to cloud platforms. Many applications are starting to employ multiple classes of AI models in combination with each other; Saha noted this requires massive amounts of data and compute resources to train those models that are only readily available in the cloud.

    Overall, AWS claims it already has more than 100,000 customers building AI applications on its platform using various tools and processor classes. AWS said in 2021 it will add G4ad Graphics Processing Unit (GPU) instances based on processors from AMD and revealed its intention to build its own GPUs next year. The company also plans to add an Amazon EC2 instance based on up to eight of Intel’s Habana GAUDI accelerators to deliver up to 40% better price-performance than current GPU-based EC2 instances.

    At the same time, AWS has extended its alliance with NVIDIA to make software modules for building AI models available on the AWS Marketplace.

    In effect, Saha said AWS is inviting IT teams to either build AI models on AWS or bring their own AI models, encapsulated in containers, to its platform.

    AWS is clearly aiming to dominate AI, regardless of how such capabilities are infused into enterprise applications. In fact, in many cases, AWS will automatically construct the AI model for customers, or simply return the results generated by an AI model via an application programming interface (API). It will be up to each organization to determine when building their own AI model makes the most sense, and to what degree they want to rely on AWS to automate the deployment process.

    What’s certain is that many of the same DevOps principles—created long before AI models ever came along—will still be relevant as the applications that use those models are continuously updated for years to come.

  • Best of 2020: SaaS : The Dirty Secret No Tech Company Talks About

    Best of 2020: SaaS : The Dirty Secret No Tech Company Talks About

    As we close out 2020, we at DevOps.com wanted to highlight the five most popular articles of the year. Following is the third in our series of the Best of 2020.

    Software as a service (SaaS) in its purest form is amazing—like compound interest, it grows upon itself and just keeps growing. Given the current climate in tech, the growth-at-all-cost playbook has been replaced with a focus on efficiency of growth. This rings very loud in enterprise SaaS.

    SaaS products are supposed to be easy to deploy and adopt. That’s the dream. It’s the reason SaaS companies trade at astronomical multiples, why they can open and expand markets faster than ever, and why venture investors (and public market investors) give them seemingly crazy valuations.

    The dirty little secret I have found is that, in most cases, this promised state just isn’t the case. The more SaaS companies I’ve seen, the more I’ve witnessed great companies forced to become service businesses to scale. Having a services team isn’t bad; it can even produce a lot of benefits for customers. But many times it ends up being necessary in SaaS.

    As with all things that involve consultants, it’s going to take longer and cost more to get your product(s) live.

    Put frankly, this process sucks, and it’s not the SaaS dream. Especially today, when organizations need to do more with less, adding heads just to get your product live seems like another problem to deal with, not a solution. SaaS products were supposed to be delivered via the cloud almost instantly. The same SaaS product was going to work for every customer, and once we built a brand, it was gonna be glorious. WTF happened?!

    I grew just as frustrated as some of you likely are. As part of the founding team at Behance (think Linkedin for the creative world), I lived this myself. We built a beautiful portfolio-sharing platform employed by millions of people, which we eventually sold to Adobe. Our platform became the engine that powered portfolios for design institutions including the Rhode Island School of Design (RISD), Savannah College of Art and Design (SCAD), School of Visual Arts (SVA), and the American Institute of Graphic Arts (AIGA), among others. We would fight for these deals with design institutions where we could step-function our member base and establish credibility in the creative world quickly just by signing up a single design school. What we found, though, was that implementations stalled for avoidable reasons. These delays would cause our team to scramble and delay accordingly, impacting critical messaging to millions of our customers.  Customers and vendors were using a different language. It drove us nuts.

    When I started angel investing in SaaS, I began to see the same story of avoidable delays all over again. Companies would have a great quarter and book more revenue than ever, but two quarters later they still hadn’t realized any revenue! What was happening?!?

    As I studied it, the issue became more and more clear: Adding more heads to an org, coupled with tons of manual processes, actually decreased operating leverage in the businesses. The teams leading implementations would dig through Excel files to try and pinpoint where the hold-ups were occurring, but there never was a good reason and everyone was blaming each other.

    I was suspicious this was a market-wide problem, but I wanted to be sure, so I started asking some friends who had built, scaled and exited large startups if they, too, were experiencing this conundrum. Carsten Thoma, who founded Hybris and later sold it to SAP for $1.5 billion, told me numerous stories about the difficulties he had getting information from his team. “I distinctly remember one senior executive meeting about a customer crisis. I kept asking seemingly simple questions and kept getting conflicting information. We just kept opening Excel spreadsheets, and it took 48 hours to get an answer that I should have had in five minutes regarding what was stalling the project,” he said. “You can imagine how the problem is compounded by a company’s size, complexity of partner network, geographic distribution and newly integrated products.”

    Carsten clearly identified that, regardless of size, companies need a way to manage and view the process of how they, and their partners implement their products. The best companies he had seen and been a part of found ways to standardize and automate processes to improve areas of inefficiency. While many times the mantra is to do things that don’t scale early to be close to customers, Carsten preached that “a process that involved the whole company and worked to get your first five customers live can’t be relied on to bring your 100th customer live.”

    To get a view from the other side of the table, I talked with some investor friends. Peter McCoy, a partner at Activant Capital, told me that during diligence his team looks to understand if a company can acquire customers efficiently. To hone in on this, he highlighted the relationship between net-new product revenue and professional services spend. This spotlights the maturity of product operations and the product itself. If the product operations are still early in their maturity, you will see a 1:1 or greater ratio. Typically this results from the company signing clients and not getting them live, overhiring in professional services to add bandwidth to non-scalable processes, and the destruction of marketing capital.

    There’s a trend here: Companies that don’t implement their products well end up hurting themselves in the long run via lower profitability and margins and fewer growth opportunities. I wanted to know more about how companies could systematize and create better processes for this workflow, so I asked Kristine Vallila, a customer success expert, about organizations she’s seen conduct implementations successfully at all scales. Kristine worked for several unicorns including Endeca and Demandware and then led customer success at NewStore.

    “So many of the delays present during implementations are the result of the same scenarios being repeated over and over. There is a need for some central fit-to-purpose tool that can provide visibility that I can compellingly champion to my executive team,” said Kristine. “More importantly, this would allow me to spend my team’s time and talent on value-add programs rather than merely delivering the table stakes. Competition in software is fierce, and customer relationships are made or broken during implementation.”

    Kristine had seen it all, yet still had the same problems. I’ve always been a runner, so I started calling her issues “false starts.”  Kristine, like everyone else, had no way to know across multiple hundreds of projects which issue would hold up which project before it happened as there was no standardization across projects to compare them and no real-time visibility into the projects to surface insights. Further, due to manual compilation, she spent the majority of her week asking for updates from clients and internal teams.  More than once, canary-in-the-coal-mine signals from existing customers were ignored because they were brought in as anecdotal examples that could not be supported with massive data. The executive team was missing out on the most important customer feedback channel via the services team.

    Having heard these stories, I’ve identified four principles by which SaaS companies must operate to survive:

    1. Optimize for product-driven growth, but consider the services team your first and most important customer feedback channel—just keep it margin positive!
    2. Standardize from day one so that all members of the company speak the same language and all projects can be compared using the same yardstick.
    3. Report to stakeholders frequently—provide information to the executive team and the client regularly about implementation progress, not just on Monday morning status/standups.
    4. Quantify your process—Create an internal NPS for implementations with clients, know where things get held up and systematize those processes.

    It might seem unreasonable that some clients who live in a world where they know within a five-minute window when their pizza will arrive hold similar expectations for tracking the progress of their enterprise-wide software projects. But it is very reasonable for them to expect better management and far clearer visibility into the critical projects for which they’re responsible.

    Earlier I stated that SaaS was like compound interest. The most important factor in compounding is to understand which variable it is applied to. My team and I hope to usher in the age of “efficient” growth. “Efficient” means that companies generate 4x every dollar invested operationally by using process, systems and structure to enable their products to be deployed with customers instead of just people.

    The dirty secret is out. It’s time for a standard here.

  • AWS Taps Grafana Labs to Launch Managed Observability Service

    AWS Taps Grafana Labs to Launch Managed Observability Service

    Amazon Web Services (AWS), in collaboration with Grafana Labs, has added a preview of managed service based on the Grafana observability platform to its portfolio of tools for managing cloud applications and infrastructure.

    The Grafana platform is based on an implementation of the open source Prometheus monitoring platform being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). The implementation curated by Grafana Labs is designed to centralize observability across multiple clusters using the same console.

    Grafana Labs CEO Raj Dutt said organizations running workloads on AWS can now more easily invoke an observability platform that runs on the same cloud platform on which they have deployed application workloads.

    In addition, Dutt noted IT organizations running workloads on AWS can seamlessly upgrade to Grafana Enterprise, which can pull information from third-party data from platforms including ServiceNow, Splunk, Snowflake, Datadog, MongoDB, Oracle, New Relic, Dynatrace, Wavefront and AppDynamics.

    Grafana Labs already offers both an on-premises edition of its platform in addition to a software-as-a-service edition. The edition that AWS is running provides access to an observability platform for applications running on AWS platforms. Organizations that want to apply the Grafana Labs platform to manage applications running on multiple platforms would employ the existing offerings available from Grafana Labs.

    The company also earlier this year added a distributed tracing platform dubbed Grafana Tempo that makes it possible to leverage existing object storage platforms and services to analyze traces. Grafana Labs also rolled out version 2.0 of Loki, which normalizes different structured, unstructured or JSON log formats in a way that allows DevOps teams to extract additional labels as well as enable additional filtering and grouping.

    In general, interest in observability is on the rise in direct proportion to the rate at which IT environments are becoming more complex. As more microservices-based applications are deployed, the level of dependency between them starts to increase exponentially. Attempting to correlate data generated by multiple monitoring tools is next to impossible, so IT organizations are starting to shift toward observability platforms that unify the collection of application and infrastructure metrics in a way that provides more context.

    Competition among providers of these platforms is already fierce, so the alliance with AWS is a notable endorsement of the approach being pursued by Grafana Labs. Less clear is to what degree IT teams will be replacing many of their existing monitoring tools once observability platforms are deployed more widely. Most existing monitoring tools are optimized for a specific class of infrastructure or application; in many cases, eliminating the licensing fees for those platforms would pay for the cost of standardizing on a single observability platform.

    Regardless of the path chosen, the way IT is managed is fundamentally changing. Each IT organization will need to adjust their IT management processes to keep pace with the rate at which IT is now becoming more complex. In fact, the next big issue may not be choosing which observability platform to select as much as it is navigating the profound changes to the internal IT culture that are sure to follow.

  • Cloud Growth and Other 2020 Trends

    Cloud Growth and Other 2020 Trends

    Growth continued this year as even the COVID pandemic could not slow down the cloud

    The rise of COVID-19 defined 2020 for nearly every industry. Cloud computing is no exception, though growth in the sector continued this year. Gartner estimates that $257.9 billion will be spent on public cloud services in 2020, up 6.3% from 2019. IDC reports that almost half of IT spending is cloud-based, “reaching 60% of all IT infrastructure and 60% to 70% of all software, services and technology spending in 2020.” These projections came in mid-2020, which proves that cloud adoption and spending were not greatly impacted by the pandemic.

    You can make the argument that cloud computing itself is the trend of 2020. Blockchain, quantum computing, machine learning and AI all deservedly earn a lot of headlines in the tech press. But at a more basic level, cloud computing is changing the way we do business. Whether it is the way they store their data, improvements to agility and go-to-market for faster release of new products and services, or how they develop and operate services remotely in today’s “locked-down world,” cloud computing is benefitting all businesses in every sector.

    In short, cloud computing had a strong year in 2020 despite COVID-19 and appears to have a very bright future. Several key trends, perhaps overshadowed by the pandemic, helped define a dynamic year for the sector. These include the following:

    • Continued Dominance of ‘The Big Four’ – All of the big four cloud providers—AWS, Azure, Google Cloud and Alibaba Cloud—reported strong growth and collectively grew 40% in Q320. Together they still account for 63% of the entire cloud sector.
    • Rise of Managed Services – The global cloud managed services market, in particular, is growing rapidly and is expected to reach $116 billion by 2025, growing from $62.4 billion in 2020, according to a study conducted by Markets and Markets.
    • Serverless and Containers – There used to be some talk about serverless and containers replacing the use of traditional virtual machines (VM). But I mostly see customers realizing that VM infrastructure is not going to disappear anytime soon, though container use certainly rose over the last 12 months.
    • Automation – The push toward greater automation continued in 2020. I noticed users accepting greater automation in their infrastructure environments, and there was simply more demand for it across the board. This is great news as one of the major advantages of a DevOps approach is automating away the manual tasks that bog down critical projects.
    • Growth in home use – This may seem an obvious one, but with the COVID-19 pandemic leading companies across the globe to new “work from home” policies, virtual desk infrastructure (VDI) usage exploded.
    • Security – Especially with a remote workforce, cloud security faced new challenges this year. One example of this playing out is in Snowflake’s massive IPO.

    Other trends of note this year included the continued growth of hybrid and multi-cloud and desktop as a service (DaaS). So, while COVID-19 truly defined 2020 for most people, the cloud sector was busy with the trends discussed above. It will certainly be interesting to see how these trends play out in the year ahead. Whatever new trends arise, it seems likely that cloud computing will continue to transform the way we all do business.

  • Morpheus Data Adds Midmarket Edition of Hybrid Cloud Platform

    Morpheus Data Adds Midmarket Edition of Hybrid Cloud Platform

    Morpheus Data announced today it is adding a more turnkey edition of its hybrid cloud platform aimed at midmarket IT organizations.

    Priced starting at $16,000, Morpheus Essentials can be deployed on VMware, Nutanix, Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), with support for Kubernetes planned.

    At the same time, Morpheus Data is updating its core platform to add support for a Plug-in Framework that provides integrations with nearly 100 cloud services without requiring DevOps teams to write code. The company is also adding support for a shopping cart capability through which third-party applications can be automatically deployed as a service.

    Finally, Morpheus Data is adding scanning tools based on the security content automation protocol (SCAP) to make it easier to embrace best DevSecOps practices.

    Brad Parks, chief marketing officer for Morpheus Data, said the goal is to reduce the level of friction IT organizations encounter when trying to centralize the management of public clouds and on-premises IT environments. With more organizations than ever now managing two or more clouds alongside an on-premises IT environment, the need to unify the management of those platforms has become more pressing, he noted.

    The current state of the economy requires IT organizations to reduce the number of management consoles they need to master for each platform, which Parks noted reduces the cost of IT labor because organizations no longer need to designate a specialist to manage each platform employed. The Morpheus platform also enables IT organizations to set up guardrails that enable DevOps teams to self-service their own requirements regardless of platform within the context of policies defined by IT operations teams, he added.

    Of course, the Morpheus Essentials edition of the hybrid cloud platform might also appeal to smaller units within larger IT organizations that need to manage a range of platforms that as yet may not be as widely employed as the platform the rest of the enterprise has standardized on.

    It’s not clear to what degree IT organizations may finally be moving to centralize the management of IT just yet, but the rise of edge computing may finally force the issue at a time when most IT teams continue to work from home to help combat the spread of the COVID-19 pandemic.

    Nevertheless, IT teams are prone to be protective of their individual fiefdoms. As such, convincing them to give up a specific platform console in favor of a platform that can be applied more widely can be a challenge. There always will be a trade-off between the capabilities available in a management console that was created for a specific platform and a management console designed for multiple platforms. The issue IT leaders will need to determine is to what degree a missing capability might have a meaningful impact on the productivity of the IT team.

    Regardless of the platform selected, the one thing that is clear is as IT becomes more complex to manage the current status quo is not likely to hold.

  • AWS Well-Architected Framework Elevates Agility

    AWS Well-Architected Framework Elevates Agility

    What started as a white paper from AWS, the Well-Architected Framework has evolved into a large ecosystem of partners and more

    In the past year, agility has become one of the most prized IT attributes as organizations race to deploy more workloads in the cloud. There is a paradox, however: The faster organizations deploy applications, the more likely mistakes will be made. Cloud computing deployments are rife with misconfigurations that are the direct result of developers provisioning cloud infrastructure rapidly and incorrectly. Application environments are almost never as efficient as they could be.

    The challenge and the opportunity IT teams now face is defining a set of best practices for securely and consistently deploying application workloads on cloud infrastructures that complement and extend agile development methodologies. IT organizations should not have to slow down application development and deployment because of security concerns. Identifying high-risk issues (HRIs) and being able to consistently achieve and maintain security without sacrificing agility is an absolute requirement.

    It seems that Amazon Web Services (AWS) couldn’t agree more. The cloud leader has defined the AWS Well-Architected Framework to help organizations build workloads on AWS that are secure, efficient, reliable, cost-optimized and operationally excellent.

    Through this effort, AWS hopes IT organizations benefit from removing the guesswork for building workloads on cloud. Cloud misconfiguration mistakes that conspire to make organizations question their commitment to agile development methodologies are eliminated. The only remaining issue is finding a set of tools that turn those AWS guidelines into a set of policies that can be achieved and enforced easily.

    Agile Meets Well-Architected

    In addition to making it possible to build and deploy applications faster, agile development methodologies make it possible to test the application code. IT teams gain unprecedented visibility into how applications behave. The equivalent of an application development methodology for managing cloud infrastructure is the AWS Well-Architected Framework.

    The Well-Architected Framework is battle-tested, based on best practices AWS has observed over its 14-year history. The pillars of the Well-Architected Framework are:

    1. Operational Excellence: Under this pillar, operations teams need to understand their business and customer needs so they can support business outcomes. Operations teams create and use procedures to respond to operational events and then validate their effectiveness to support business needs. Those teams also collect metrics that are used to measure the achievement of desired business outcomes. It’s important to design operations to support evolution in response to change and to incorporate lessons learned through their performance.
    2. Security: This pillar focuses on the importance of putting in place practices that influence security before any workload is architected. IT teams need to control who can do what. In addition, they need to be able to identify security incidents, protect systems and services, and maintain the confidentiality and integrity of data through data protection.
    3. Reliability: This pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total life cycle. The workload architecture of the distributed system must be designed to prevent and mitigate failures, handle changes in demand or requirements and be able to detect failures and automatically heal itself.
    4. Performance Efficiency: This pillar addresses the need to use computing resources efficiently to meet system requirements and to maintain that efficiency as demand changes and technologies evolve. Teams must gather data on all aspects of the architecture, from the high-level design to the selection and configuration of resource types and make trade-offs in their architecture to improve performance, such as using compression or caching or relaxing consistency requirements.
    5. Cost Optimization: This pillar focuses on how to run systems to deliver business value at the lowest price point. Design decisions are sometimes directed by haste rather than data, and it can be tempting to overcompensate rather than spend time performing benchmarking to determine the most cost-optimal deployment. As a result, deployments can be both overprovisioned and underutilized. Using the appropriate services, resources and configurations for workloads is key to cost savings.

    Each of these pillars requires tools to enable DevOps teams to proactively manage their cloud environments—not only by provisioning and deploying applications faster but also by making more informed decisions when considering trade-offs between performance, reliability, cost and security. It’s a balance as rarely are these decisions independent of each other.

    The COVID-19 Imperative

    The COVID-19 pandemic has made the Well-Architected Framework essential. The number of workloads being deployed on AWS has increased sharply as organizations of all sizes accelerate digital business transformation initiatives. IT projects that once were expected to take months to complete now are expected to be up and running in a matter of weeks.

  • Split Allies With AWS to Advance Feature Flagging Adoption

    Split Allies With AWS to Advance Feature Flagging Adoption

    Split today announced it has integrated its namesake platform for managing feature flagging with the Amazon’s Simple Storage Service (Amazon S3) as part of an effort to streamline the process of adding new capabilities to applications.

    Company CTO Pato Echagüe said one of the most challenging aspects of feature flagging is providing a way for development teams to access data required to test those capabilities. Integration with Amazon S3 will now make it possible for Split to ingest millions of customer events per minute as Parquet files from Amazon S3.

    That capability will make it possible to have enough statistically relevant data to analyze how a feature is being employed within minutes, said Echagüe. Previously, software engineers would have had to spend hours manually configuring the Split feature flag management platform to ingest gigabytes or terabytes of data, he noted. The integration with Amazon S3 makes it possible to now analyze terabytes of data in near real-time.

    Split next year also plans to make it possible to send feature flag data to Amazon S3, where it can be combined with other types of data that could be analyzed using a third-party application.

    The end goal is to make it easier for product and engineering teams to collaboratively iterate new features and capabilities faster in a way that aligns better with a product road map, added Echagüe.

    Interest in feature flagging has been on the rise as organizations invest in digital business transformation initiatives to better engage end users that are working from home to combat the spread of the COVID-19 pandemic. Feature flagging capabilities make it easier for those organizations to test new capabilities without having to expose every ens user to a capability that ultimately may not have enough appeal to be included in the application.

    Feature flagging, of course, is already employed within many DevOps workflows. Split, however, is providing a platform that is designed to make it easier for DevOps teams and application owners to collaborate on the rollout of features based on feedback from end users regardless of what DevOps platforms application development teams are employing, said Echagüe.

    As IT becomes more complex, Echagüe noted it’s more important than ever for organizations to have a consistent approach to change management. The bulk of issues many IT organizations wind up addressing usually have something to do with a recent change to an application, he said.

    There’s no doubt that as organizations begin to rely more on digital processes, organizations will want to have more confidence in the capabilities being added to these platforms. As a result, many application owners who don’t have a lot experience working within the context of a DevOps workflow still want to be able to exercise and maintain control over what features are added to an application.

    Regardless of the approach to feature flagging, it should be apparent to all involved by now that this capability going forward is going to play a much larger role in application development and deployment.

  • Data Security in the Cloud with Imperva

    Data Security in the Cloud with Imperva

    Database security startup jSonar, founded by Ron Bennatan, was recently acquired by Imperva, a leading cybersecurity company focused on data and application protection.

    In this episode of TechStrong TV, Ron Bennatan, general manager of data security at Imperva, joins us to discuss the plethora of data security challenges across cloud environments. They also talk about the significant increase in data usage and creation as a result of COVID-19.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I have the pleasure of being joined today by Ron Bennatan, who is GM of Imperva Data Security. Welcome, Ron.

    Ron Bennatan: Thanks. Glad to be here.

    Ashley: Good to be talking with you. I’m excited to chat a little bit about data security. Let’s start out with, just introduce yourself, a little bit of your background. I know you had a recent event with your company, Imperva, and tell us a little bit about what Imperva does.

    Bennatan: Okay, yeah. I’ll just start with what Imperva does. So, we’re a cyber security leader, we have over 6,000 global customers and we’re just focused on helping them protect data and all paths to it. And kind of what that means is, we have both application security products and data security products, both of them leading in those spaces. 

    But kind of the, our view is that, in order to do a good job around data security, you really have to look at this as a whole thing, otherwise it becomes, like, a blanket thing, right? You pull it to one direction and you expose yourself on the other side. Because data is—yeah, it’s very complex. And securing all data and all ways that people access data is a difficult thing.

    So, like, for example, I could be—I could be really good at securing access to data from privileged insiders, but then you also get access through the applications. And the way that the data tier looks at things, it doesn’t see enough when it’s accessed through the application, so that’s a problem. And then if you do a good job on the application side, you know, maybe on bots and APIs, but maybe you also have insiders, and maybe insiders are different when they access it directly or they’re admins of the data tier or they’re admins of the application tier.

    So, really, our view is, in order to do a good job, you really need to look at the whole access and all the paths to it.

    Ashley: Excellent.

    Bennatan: How did I get here? So, I’m a 30-year data-slash-security guy, so I’ve been both, kind of working on the data side, whether it’s a DBA or application side, but also on the security side.

    So, I started my career in the military. I then worked on Wall Street for a while, areas around Sybase and Sybase security, Oracle and Oracle security. Then I was one of the founders of Guardium back in the early 2000s, built this database security business, got acquired by IBM, was the CTO of data security at IBM for a while. Last, founded jSonar, also in the data security space, and then a month ago got acquired by Imperva, so I now lead the data security setup there.

    Ashley: You just keep getting acquired. I need to hang out with you a little bit more.

    Bennatan: [Laughter] 

    Ashley: [Laughter] Going back to Sybase—wow. Yeah, I was a Sybase customer. [Cross talk] 

    Bennatan: [Laughter] You know, it’s still being used all over the place.

    Ashley: Isn’t it amazing? Technology never goes away.

    Bennatan: It never goes away.

    Ashley: We just don’t talk about it as much as we used to. [Laughter] Well, you know, data security is such a fascinating topic. And I don’t mean this in a pejorative way, but it’s a bit like whack-a-mole, right? It’s everywhere and as soon as you think you’ve kinda gotten control over it, it pops up over here, sorta like that balloon that squeezes between your fingers, [Laughter] you think you’ve got your hands around it. And plus, it’s not a static thing, it’s growing and it’s evolving, it’s being used by different applications in different ways.

    It’s a huge challenge. I mean, how do you even begin to tackle that from a data security company?

    Bennatan: Yeah, so, I mean, first of all, you’re absolutely right. And, you know, we’re all security professionals, so to us, it looks like a bad thing, but before we go down that route, it’s actually a good thing, right? 

    I mean, the fact that it is so complex, it is because it’s just hyper efficient, right? The people who are building data architectures are amazing. They’re doing an amazing job. Because if you look at data architectures 20 years ago or even 10 years ago compared to what they are today, it’s just—it’s like, it’s like an immature baby compared to what’s happening now.

    Ashley: Mm-hmm.

    Bennatan: And it’s a good thing, because these are highly optimized systems, very diverse types of workloads, very diverse technologies, right? A database today is not even close to what it was 20 years ago. A data lake today is an amazing thing, okay? You know, it’s hard to even put your finger on exactly what it is, a data lake, when you look at, say, an AWS data lake or an Azure data lake or a GCP data lake. They’re amazing.

    So, these are good things, right? Our applications are getting better, they’re getting faster. We can do, like, crazy things with machine learning algorithms doing analysis, telling us how to improve our lives, okay?

    Now, as security people, we’re always playing catch up, okay? We’re always—these people are creating these things, and security is never exactly baked into that stack, although it is getting a little better or we’re trying to get it a little better. So, we are playing catch up, and it does create a lot of challenges on what it means to secure it well. 

    So, you know, the fundamentals have never really changed, right? There’s authentication, there’s authorization, there’s audit, there’s the notion of finding where the data is, classifying the—that stuff doesn’t change. What does change is the complexity of doing each one of those tasks.

    So, if you look at—you know, even the first thing you kind of need to start looking at is, you know, find all your sensitive data and make a catalogue of it and know the lineage and—you know, 40 years, we’re doing the same thing. And it just gets harder and harder, because you look at one of these data lakes, you know, I think 10 years ago, when we were building a data lake or thinking of a data lake, we would think of, “Okay, we’re probably doing some kind of a Hadoop project,” okay?

    Ashley: Mm-hmm.

    Bennatan: Which, in itself, was complex enough as it is, because you’ve got, like, eight or nine different services running, each one doing something a little different.

    Ashley: It wasn’t that long ago. I mean—

    Bennatan: It wasn’t that long ago, but it’s dead, right? It’s [Laughter]—that part’s dead. Now, we’re building something which is infinitely more complicated. Because—like, I’ll give you an example. A lot of my customers are building things on AWS.

    So, you’ve got this—it’s not like the data lives in one place, okay? You’ve got S3 buckets, and then you’ve got access sometimes from Athena, sometimes through Spectrum, sometimes from both. And then you have some DynamoDB or DocumentDB databases for doing transient things, and then you shove it into Redshift so your Tableau can access it. And then you have AWS Glue moving things around, and maybe you even have a Hadoop stack inside EMR for the landing area.

    Ashley: You have data in databases inside containerized—

    Bennatan: Yeah, everywhere. And then you say, “Well, how do I secure one of these beasts?” And so, yeah, it’s complicated, it’s risky, and we just need to keep up with these guys who are doing a good job with making very innovative architectures. And, you know, it would be great, by the way, if we could’ve baked this into the stack before they even started, okay?

    Ashley: Mm-hmm.

    Bennatan: But, like, I’m too old to believe in fairytales.

    Ashley: You stopped chasing that rainbow, right? [Laughter]

    Bennatan: Yeah. And we just do need to keep up with them. We need to keep up with them, we need—you know, because a lot of my customers are larger, and if they’re larger, then sometimes they’re regulated, somehow, or they need to adhere to something.

    Ashley: Mm-hmm.

    Bennatan: And certainly, these days, they’re all also troubled by all kinds of privacy compliance issues. So, we need to give them controls that they’re used to getting, you know, on the stuff that they’ve been building for the last 30 years on prem. And it gets to a point that the application team wants—you know, they’re ready. They finished everything, they’re migrating it up, and even simple things, not even complex things like cloud. They have an application using SQL on prem and they want to move it to SQL on Azure—simple enough, right?

    Not really, because on prem, they know what their tooling looks like, they know what their controls are, they know what they’re doing with privileged access, they know how to scan, they know how to create the policy for defining access. They know how to manage—they know how to do change management around that policy. Now, they all move it to the cloud. Sometimes, those controls are there; more often, they’re not there. 

    And, you know, so, for example, one of the things that we view as being fundamentally important for us is to make that transition seamless, okay? Same controls. Different methods, different tools, different policy orchestration, but to them, it should look the same. If it looks the same, then when the app team wants to move it over, security stops being this bad guy that says, “Nope, stop. Okay, tell me what you did, here.” 

    I mean, we can’t be the bad guys, okay? We have to—

    Ashley: Can’t be the cops, can’t be the roadblock.

    Bennatan: Yeah, yeah. We need to help. We can’t keep stopping things. It’s just a bad, bad—bad dynamic.

    Ashley: So, let me ask you. There’s so many dimensions to this and usages of data. So, is that one, instead of, like, getting ahead of all of it and designing it up front, which we wish we always could and doesn’t happen—is that the right approach?

    I’m thinking about how do we do security right—is that creating the, whether it’s the tooling or the framework or the structure of how we secure data, making that consistent so, no matter the environment, we now know how to do it, and we can do it in a reasonably consistent way and know that it’s been done as opposed to, you know, n+1 for every environment that we’re in, it’s all different and it’s all complex and nobody can keep track of any of it, more or less secure it. Is that sort of getting our hands around this problem?

    Bennatan: Yes, that is absolutely the one sentence summary is exactly that.

    Ashley: A lump sentence, but [Laughter]—

    Bennatan: A lump sentence. [Laughter] Yeah, yeah, because we need to—we need to abstract things out and hide the complexity, right?

    Ashley: Mm-hmm.

    Bennatan: We need—the fact that the data environment is so complex, it doesn’t change that if you go high enough, the problem statement or the what you need to do statement is the same, okay? The problem is that when you translate it to, “Okay, what actually happens?” then it tends to be different here, different here, different here.

    But at a high enough level, it’s exactly the same thing. So, you know, what—if the environments are getting more sophisticated and the architectures are getting more complex in a good way, if securing them also gets more complex, then we’ve lost. So, what we need to do is make it maintain a single abstraction layer, and then do the magic that translates it into the individual changes.

    So, it’s absolutely what we need to do. Now, some of this is a heterogeneous question. Okay, some of it is a heterogeneous thing where, you know, you have different silos and you know, historically, people have always looked at data as a bunch of silos.

    Ashley: Mm-hmm.

    Bennatan: Okay, there’s like the database silos, the big data silos, the file silo. That stuff gets blurred (a) because in the cloud, it’s very blurry, okay? Like, you can definitely say that S3 is a file system, okay? It’s an object store, it’s kind of like a file system, but then you slap a FINA on top of it, and that gives you SQL queries on top of that file store. So, is it now a file system, or is it a SQL database? What is that thing? It’s—

    Ashley: And DynamoDB and now you’ve got a whole bunch of different ways of accessing and using that data.

    Bennatan: Yes. So, that’s one piece of it. The other piece of it, which is almost the same sentence that you said, but semantically, it has a different meaning, okay? If you look at kind of the concept of data governance, okay, from—in the last 20 years, it’s always been, like, at the top, there’s things like policy and things like, you know, what are the business requirements? And at the bottom, there’s the tooling. And always, whenever you talk to anybody in this space, they always say, “Don’t start here, don’t start at the bottom by just implementing tooling, start here and then do this.” Well, I’ve yet to meet a single company that has started here. You always start here.

    Ashley: When do you get the luxury, right?

    Bennatan: Yeah! Look, part of it is just us people, okay? We’re—us people are problematic, okay? [Laughter] People can understand very concrete things very well, and therefore, we can go do a project that does this and we can do a project that does—and the vendor landscape has never helped, because products are like this and like this, so… And you go to the analysts, and the analysts say, “Oh, you need to pick one of these and one of these and one of these.”

    So, you know, for many years, it’s been one of these, “Okay, nobody started here, everybody started here.” And then projects have operationalization problems. It’s not that, you know, tools have problems, it’s the fact that, even if a tool does everything it was supposed to be doing, it gets hard to operationalize things. And then you start looking at it and you say, “Okay, within these silos, there’s actually no difference to operationalize things.” It’s the same thing, okay? You need the same processes, you need the same decisions, you need the same policy push down.

    So, why are we doing it six times? Why are we not doing it one time? Well, we’re not doing it one time because we didn’t start here. And so, over time, you know, I kind of gave up on people starting here and assumed people would always start here. The question is, that abstraction—can you now take work that you’ve done within any one of those silos and leverage that in order to create that kind of in the middle, like a single control layer, okay?

    Ashley: Mm-hmm.

    Bennatan: I mean, a single control layer that then uses those tools, but creates something that is, you know, consistent. And if you start creating something that is consistent, then you’re not, you know, you’re not balled into these silos. And then when you’re—when you get some of these more kind of advanced architectures, you know, you’re not screwed, because you didn’t create something just for this silo and this silo and this silo.

    Ashley: And then you know that all the bases are covered, too, you’re not having to do a unique process or solution for all the checkmarks you’ve got to put in place, and who knows if those work reliably in every environment, whatever way you figured out to secure the data or do access control or manage data integrity, whatever that is.

    Bennatan: Yeah.

    Ashley: Let me ask you. I think, maybe other than you getting acquired by Imperva, most of us want to put a checkbox on 2020, kinda wrap it up and, you know, in cellophane, put it into a bucket of cement and drop it in the river, you know? [Laughter] Kinda, let’s get past this year and move on to 2021.

    So, as you think forward in getting security right, we’re in this COVID era, right? And, you know, that light switch isn’t gonna turn off any day soon. We’re gonna be some evolution of this for, you know, whether there’s vaccines or not, right? But that has rapidly, I mean, seriously accelerated digital transformation projects, and changed some things fundamentally about assumptions we make. We’ve kinda, we can go to shed some of that evolution and we’re there, in many cases.

    How has that affected your thinking around data security in this era? Because we’re in it, we’re not heading towards being transformed, we’re living it right now.

    Bennatan: Yeah. You know, I think this is actually one of the few positive side effects of COVID, you know? I can’t tell you how sick I am of being here. I need to go somewhere. I really need to go somewhere, I’m like, sick, but—

    Ashley: I know. What day is it, anyway? I can’t figure it out.

    Bennatan: Yeah. I just, I just can’t even tell you. [Laughter] But the acceleration that this has given to cloud projects is one of the side effects that I think is very positive. Because, for years, you know, I’m a technology guy, and you know, if it were up to me, everything would be on cloud, bar none. Nothing, nothing—there would be scorched earth everything else. And, you know, I keep hearing people saying, “Yeah, but you know, it’s more expensive.” You know, it’s more expensive only if you look at it at the actual numbers of the cost you pay the cloud providers. But if you look at how much more effective it is and how much easier, it’s like buying super-duper IT, okay?

    Ashley: Mm-hmm.

    Bennatan: That’s really what it’s about. It’s not about anything else, it’s about finding people who know exactly what they’re doing and that you never get to a point that you always have when you build your own stuff where you’ve got people finger pointing, you know? “No, it’s a storage problem,” “No, it’s a host problem”—it just works, okay?

    So, I think it’s great. I think it does create a lot of challenges or security, just because it’s very new, okay? It’s very new and it’s very, very fast. And new doesn’t mean it’s, like, six months old. But even if it’s six years old, it’s all new. It’s like, somebody built everything that anybody built around data centers from scratch, really, okay? Or it looks different or it’s called different. 

    And then the problem—again, going back to people, the problem is always people. So—so, a lot of companies, what they’ve done in order to accelerate this very, very quickly is, they’ve built a separate security architecture for the cloud group to parallel the cloud architecture group, which is different from the old guys, okay?

    So, now you get people who understand data security pretty well, because they’ve done it for many, many years. You have people who understand data very well. And then you have people who understand cloud very well, but they’re not the same people, okay?

    Ashley: Mm-hmm.

    Bennatan: So, now, you get a skills issue and almost like a language issue, okay? It’s like Babel again in some respects. It’s like, how do you call this? What is this? Is it the same? You know, what’s a VPC, how many different ways do you have to connect things into a VPC? What does that impact my data architecture, and what are the flows?

    And so, I do look at 2021 as a great, great year, because, you know, if people have been going at a certain pace into the cloud, it’s all accelerated. It’s—

    Ashley: You know, I think that is a really important point, because when you’ve been disrupted—and we’ve all been disrupted in our personal lives, but when you accelerate something that fast, you know, the saying, “necessity is the mother of invention”? Well, necessity with urgency is, like, the mother of invention right now.

    Bennatan: Yeah.

    Ashley: And it’s almost like you can’t do things the way you’ve been doing, you can’t go along in parallel paths, because suddenly we’re all now here. We’re all in the cloud together or in a place that’s much different than we were.

    Do you think that that is enough of an accelerant to get sort of those silos of people across cloud security and on prem security and those start to work together of thinking how we manage? Because so much more of it now has moved to the cloud—or is that a good assumption? I mean, tell me what your thoughts are.

    Bennatan: Eh, you know, it’s—because it’s people—

    Ashley: [Laughter]

    Bennatan: – [Laughter] I, I don’t know how to answer that, you know? We’re getting into the realms of psychology more than anything. But I can tell you that, you know, it’s gotta happen, and we’re gonna make mistakes, right? As an industry, we’re gonna do this, it’s good that we’re doing it. And we’re gonna make more mistakes, because it’s less known, because we don’t always have the right skills.

    Ashley: Mm-hmm.

    Bennatan: And I think it’s our job, you know, our job in the industry is to try to reduce those mistakes. Because mistakes lead to things that we don’t want to happen, and we do have the ability to avoid mistakes, okay? We just need to be very clear—we can’t be, like, super techies about it, okay? We have to do things that are practical. Because what you asked is about human behavior. So, really, it’s not enough we create technology, we need to create technology that is accessible to people and that people can consume very easily.

    It’s one of the things that, kind of, in security, I think we never—I think we’re doing a much better job now, and my entire focus is really on this, on making things practical and usable very often more important than a certain feature function, okay?

    Ashley: Mm-hmm, mm-hmm. I totally agree with that, yeah. Well, you know, what I was thinking about is that, when you have that disruption, think about choosing productivity tools. How many organizations were debating, “We’re gonna go to Teams, we’re gonna go to Slack, let’s study it for a year” and it turns into two years and you final make a decision. All of a sudden, that decision gets made in two weeks or a week or a day—a couple days.

    Bennatan: Yes.

    Ashley: Like, how could—you just have to. You’re forced to make some decisions and make some changes.

    What I’m wondering is, if you accelerate to the cloud and you have, you know, a framework, an architecture, something like an Imperva that—okay, we’ve solved some of those issues, let’s just solve them for other folks and help each other save some time, right? You don’t have to—sure, check me out, validate it, you think this is all the right thing to do. But if you’ve got to do something quick, we’ve got a good bit of that problem solved. It seems like you’re in a good position from that standpoint.

    Bennatan: Yeah, and I do believe so. I think that we started very early with the cloud and how do you do this well, and so we are in a good position.

    I also really [Laughter]—you know, you said something about this productivity tools making the decision in two weeks, and it’s one of my, you know, one of my pet peeves for my entire life has been something—I don’t see it changing, by the way, yet, but I really wish it would change, okay? Is this concept of a POC, okay? Where you—you know, you need something, like, go back to your two years versus two weeks. What does that mean? It means, somebody picked without doing a POC, right? [Laughter] 

    Ashley: Make a bet and if it’s wrong, we’ll change it.

    Bennatan: Okay, make a bet, and make a bet based on what? You made a bet based on, you know—

    Ashley: Best [Cross talk].

    Bennatan: – either something that’s more usable or very usable, [Cross talk] or something that everybody else is using.

    Ashley: [Cross talk] at the result. I think that’s what it comes down to, right? What is gonna get us the quickest understanding? Nothing’s gonna be perfect, we’re gonna have issues with whatever we choose already, of course.

    Bennatan: Yeah, yeah, and this entire industry forever has been, “Okay, I can’t pick anything until I do a POC, but when I do a POC, I’m actually not even checking what’s important, because I can’t reproduce my production environment. I can’t reproduce the load, so I’m just gonna test something, okay? I’ll test, like, really simple things—can you do this, can you do that?”—which has absolutely no bearing on whether you’ll succeed or not.

    And what I’m starting to see, especially on the cloud, because it’s much easier to just look at things, much easier to talk to people, much easier to see what your colleagues are doing, what your peers are doing is, I’m hoping that that accelerates things. Because if we need to do something tomorrow, we’re just not gonna wait. We’re not gonna wait nine months.

    Ashley: So, here’s what might start to change that behavior. I’m not gonna proclaim that it’s changed that behavior, but through this COVID experience, using that productivity tool example—guess what? Executives, the non-techies of the company, look at us and say, “How come we can make a decision in two days when we were gonna take two years to do it? If we can make that decision in two days, I want us to make the other decisions quickly. Maybe it’s not always two days, but we’ve proven we can make some good decisions under some very difficult conditions and rapidly. Let’s exercise and build up that muscle and do that more often than the thing that we debate about forever.”

    Bennatan: Yeah.

    Ashley: So, I think there may be some pressure from the business, who’s also, by the way, very disruptive, they’re having to adjust, they’re having to go into defense or offensive mode in the business climate, and they want to be able to experiment very quickly—that’s part of what digital transformation is about, right? Try some things, experiment, and market, go after—you know, learn quickly, much like we do in kinda continuous improvement.

    So, that might be the thing that nudges us off of the comfortable stool of, “Let’s take nine months-slash-two years to study it and make a decision or run it—you know, do an RFP for everything.” I hate RFPs, but—

    Bennatan: Yeah.

    Ashley: – just like POCs for you. [Laughter]

    Bennatan: Yeah.

    Ashley: But maybe that’s the thing that tilts it a little bit. I mean, I’m not gonna declare success yet, but…

    Bennatan: I agree, I agree. I think it’s—you know, I’ve been in startups all of my life, okay? So, one of the things that is really fundamental when you look at a VC that’s investing in a company, they’re investing in the people, not in the company.

    Ashley: Exactly.

    Bennatan: I mean, this technology, they don’t know yet, okay?

    Ashley: They know you don’t have it figured out, otherwise somebody else would’ve done it.

    Bennatan: Yeah, yeah.

    Ashley: Right? So, your job is to figure it out, but get the right people that can do it.

    Bennatan: But they invest a lot of money very quickly, okay? They don’t take nine months, right? So, I believe that, you know, when people look at their partners, who they’re gonna partner with, they need to look at, you know, what are the founding principles of the company? How much is the company gonna care about me? What is it gonna do for me? Are they gonna be there when I need them?

    And I’m not saying technology’s not important, because product is everything, but it’s product and the people that stand behind it, and the decisions need to be made, also, from the business level.

    Ashley: So, we’re kinda running up against our time, here. I’m gonna point out this irony and hopefully you’ll come back and talk about it. So, you were just talking about investing in people, which is what VCs do, I totally agree with that. And earlier we were talking about—well, the problem we were talking about is human behavior and people, right? So, [Laughter] there are conditions of which will drive different behaviors, and hopefully that’s something we can explore about data and data security some more. We’ll have you back again soon.

    Bennatan: Yeah. Okay, I’d love that.

    Ashley: Good. Well, Ron, it’s been a pleasure. I wish you all the best. Congratulations on the acquisition and hopefully, you’ll be able to get out of your four brick wall cell there at some point and get out and enjoy the world again. [Laughter]

    Bennatan: [Laughter]

    Ashley: All of us will, but I wish you the best. It’s been great talking with you.

    Bennatan: Hopefully. Thanks, Mitch.

    Ashley: Great. Thanks for joining us today, folks. We’ll talk to you soon.

  • Copado Adds Value Stream Management to Salesforce DevOps Platform

    Copado Adds Value Stream Management to Salesforce DevOps Platform

    Copado, a provider of a DevOps platform for building applications that extend software-as-a-service (SaaS) applications from Salesforce, this week announced it has added value stream management capabilities.

    Andrew Leigh, chief marketing officer for Copado, said providing a platform that accelerates the development and deployment of application code is no longer sufficient. The winter 2021 release of the Copado DevOps 360 platform now includes value stream management capabilities that enable organizations to better prioritize DevOps projects, he said.

    In response to the COVID-19 pandemic more organizations than ever are now relying more on SaaS applications that can be accessed easily by employees working from home. IT organizations are also now using platforms such as Salesforce to jumpstart digital business transformation initiatives. Rather than write develop entire applications from the ground up, many organizations are employing low-code tools from Salesforce and others to extend, for example, customer relationship management (CRM) platforms.

    Leigh said most of the activity revolves around professional developers who are increasingly applying best DevOps practices to build those applications. Copado has certified more than 25,000 developers on its platform, he said.

    Given the current state of the economy, Leigh said interest in DevOps platforms is rising among organizations building Salesforce applications because they want to ensure a return on investment (ROI). Organizations that are investing six figures to build these applications are especially interested in value stream management tools that help make sure these projects are delivered on time.

    The value stream management capabilities added by Copado include support for the Scaled Agile Framework (SAFe) for building complex applications more efficiently. It also provides the ability to synchronize stories from Jira and Agile Planning boards.

    The latest version of the Copado DevOps 360 platform also adds a suite of declarative pipeline builders that allow non-technical teams to define and manage value pipelines without a single line of code. That capability is intended to simplify version control and automation flows to enable developers and administrators who manage Salesforce instances to better align their efforts.

    Copado added deeper integrations to third-party testing tools that incorporate artificial intelligence (AI) and updated its static code analysis and compliance tools.

    Salesforce is clearly not the only SaaS application platform that organizations are looking to extend, but it is among the fastest-growing. For its most recent third quarter, the company posted revenues of $5.42 billion, an increase of 20% year over year. The company is now lifting its future guidance to slightly exceed pre-pandemic levels. Salesforce is projecting fiscal 2021 revenue at the end of its fourth quarter will total $21.11 billion. Revenue guidance for fiscal 2022 has been raised to $25.5 billion. Salesforce earlier this week also announced its intention to acquire Slack, a provider of a messaging platform that is used widely by DevOps teams.

    Leigh said a dedicated DevOps platform for Salesforce applications is necessary because Salesforce applications are constructed using a set of objects and tables unique to the platform versus traditional application code. Regardless of the reason for requiring a dedicated DevOps platform, interest in building and deploying custom applications on top of the Salesforce platform has increased sharply since the start of the pandemic.

  • Atlassian Embeds Metrics for Measuring DevOps in Jira

    Atlassian Embeds Metrics for Measuring DevOps in Jira

    Atlassian today announced it has added four features to Jira Software Cloud that allow developers to visualize and measure progress across DevOps workflows.

    Suzie Prince, head of product for DevOps at Atlassian, said rather than organizations having to acquire and deploy separate tools to track DevOps metrics, Atlassian is moving to incorporate those capabilities in a platform that is already widely employed to manage application development projects.

    Two capabilities being added to the standard edition of Jira Software Cloud are Code in Jira, which makes it possible to view the most recently active repositories in Bitbucket, GitHub, GitLab or Git Integration for Jira from within Jira Software Cloud, and Deployments in Jira, which makes it possible to similarly view in real-time at what stage any deployment is on any continuous integration/continuous delivery (CI/CD) platform.

    The Premium Edition of Jira Software Cloud is gaining tools to track both deployment frequency and cycle times to provide more insight into how application development teams are maturing in terms of their overall DevOps proficiency.

    These tools eliminate the need for analytics tools that otherwise would be required for each DevOps platform an organization employs, noted Prince. Jira Software Cloud also exposes a REST application programming interface (API) through which DevOps teams can integrate the Atlassian platform with other DevOps tools.

    It will be up to each organization to determine how they may want to employ the insights surfaced within Jira Software Cloud. However, Prince said most IT teams should identify areas of weakness where there is an opportunity to coach DevOps teams on how to improve.

    There is, of course, a lot more focus on improvement as application development projects have accelerated in recent months, thanks mainly to the increased focus on digital business transformation. Organizations of all sizes are trying to maximize investments in application development at a time when the economic downturn brought on by the COVID-19 pandemic is forcing IT teams to make difficult tradeoffs. Metrics, of course, are critical when it comes time to prioritize one project over another.

    At the same time, Prince noted that many teams are trying to keep the number of tools and platforms incorporated into a DevOps toolchain to an absolute minimum to limit costs and minimize complexity. Many DevOps teams have been employing Jira software to manage application development projects for years now, so Prince said these new capabilities are a logical extension of the company’s project management software.

    Of course, the best metrics are the ones that manifest themselves automatically. No project manager relishes having to badger developers to enter data into a project management application. The more the data residing in a DevOps platform can automatically populate a project management application, the happier all involved will be. After all, the goal is to head off as many issues as possible today before they become major problems tomorrow.