devopsy.kinsta.cloud

Category: DevOps Toolbox

  • Survey Surfaces Observability Challenges in the Cloud Era

    Survey Surfaces Observability Challenges in the Cloud Era

    A recent cloud observability survey found nearly two-thirds (64%) of respondents reported the adoption of public clouds has made it more difficult to achieve observability. Nearly half of respondents (48%) said they now consider providing real-time insights into application/infrastructure environments to be a top priority.

    The survey polled 357 IT professionals and was conducted by Enterprise Strategy Group (ESG) on behalf of Yotascale, a provider of cost optimization tools for cloud computing environments.

    Yotascale CEO Asim Razzaq said that attaining and maintaining observability becomes more challenging with each new cloud platform adopted. The survey found that 71% of organizations now rely on more than three cloud infrastructure providers.

    A full 84% of survey respondents also noted that tracking costs and cloud cost allocation is burdensome and time-consuming, and 61% admitted they lacked sufficient visibility into which teams own what cloud resources. Nearly a quarter (24%) are considering making changes to their monitoring and observability practices as infrastructure costs rise.

    Observability has always been a core DevOps tenet, but achieving and maintaining it is challenging. Most DevOps teams today aspire to be able to maintain some level of continuous monitoring. However, as it becomes easier and less costly to instrument applications, interest is rising in observability platforms that simplify the investigation of anomalies indicative of an issue that could disrupt an application environment. As that shift occurs, more organizations will seek to correlate events with costs as part of an effort to rein in the costs of IT, said Razzaq.

    In the immediate aftermath of the COVID-19 pandemic, the number of workloads being deployed on public clouds increased sharply. In theory, many organizations signed enterprise licenses that reduce cloud costs if they consistently consume a certain level of infrastructure resources. In practice, however, individual developer teams are showing a preference for one cloud platform over another based on the attributes of their workloads. As a result, however, it becomes more challenging to not only consistently observe diverse platforms but also to control costs.

    It’s still early days as far as the adoption of observability platforms is concerned, but it’s apparent that as application environments become more complex the plethora of monitoring tools that DevOps teams rely on will need to be streamlined. It’s not uncommon for DevOps teams to have multiple monitoring tools that surface a set of pre-defined but often conflicting metrics. Observability platforms unify logs, metrics and traces in a way that makes it simpler to launch queries to identify the root cause of an issue.

    The rate at which DevOps teams will embrace observability will naturally vary. In 2022, the biggest obstacle might not be the technology as much as it is simply understanding what queries can help DevOps teams better understand the root cause of an IT issue before there is a major disruption. In the long term, it’s expected that machine learning algorithms will leverage the data collected by observability platforms to automatically identify issues that might lead to a disruption long before it actually occurs. Regardless of approach, however, the ability to manage complex IT environments in the months and years ahead will continue to steadily improve.

  • ServiceNow Launches Incident Management Platform Infused with Observability

    ServiceNow Launches Incident Management Platform Infused with Observability

    ServiceNow added an incident management platform based on the Lightstep observability platform it acquired last year to its software-as-a-service (SaaS) portfolio.

    Ben Sigelman, general manager of Lightstep at ServiceNow, said Lightstep Incident Response gives DevOps teams access to observability tools that, via a self-service portal, enable them to determine the root cause of any incident much faster. It combines the ability to orchestrate on-call escalation, alert grouping, incident analysis and remediation with a set of collaboration and incident management tools.

    That approach will make the Lightstep observability platform much more accessible via a cloud service, noted Sigelman. The Lightstep observability platform itself is based on a time-series database capable of processing one trillion events each day.

    Lightstep Incident Response manages an organization’s on-call rotations by synchronizing schedules via a shared calendar, with specific tags that indicate who needs to be looped in based on the nature of the incident and the service that is impacted. Team members are invited to a dedicated channel based on prebuilt collaboration integrations for quick remediation. Over time they can create automated processes that self-triage and self-remediate problems as they reoccur. The platform also integrates with monitoring, observability and collaboration tools such as LogicMonitor, Postman, Slack, Sumo Logic and Zoom.

    Lightstep Incident Response is generally available now in both free and paid versions. Pricing is based on the use of active services being managed rather than by seat license.

    Lightstep Incident Response also natively integrates with the Now Platform that ServiceNow created for IT service management (ITSM). That integration will enable organizations to more easily meld ITSM and DevOps workflows, noted Sigelman.

    Observability platforms aggregate the collection of logs, metrics and traces in a way that makes it possible for DevOps teams to query that data. The goal is to make it easier for DevOps teams to identify anomalies that might disrupt an application environment. Those same tools, however, also allow DevOps teams to identify the root cause of an IT incident much faster. Today many organizations routinely convene “war rooms” that require IT teams to painstakingly identify the root cause of an issue by a process of elimination; this can take days—sometimes even weeks—to complete.

    With more applications becoming instrumented—thanks, in part, to the availability of open source agent software—Sigelman said observability platforms will play a critical role in helping to automate incident management processes. Prior to being acquired by ServiceNow, Lightstep team members played a role in the creation of both the OpenTracing and OpenTelemetry open source projects for collecting traces, metrics and logs. Today, OpenTelemetry is a sandbox-level project being managed under the auspices of the Cloud Native Computing Foundation (CNCF).

    With the deployment of more microservices-based applications, the percentage of applications that are instrumented will soon increase substantially. It’s not feasible to manage these highly distributed applications without some level of instrumentation. The issue now, of course, is determining to what degree to also instrument many of the monolithic applications that are already running in those same environments.

  • 7 Steps to Unleashing Your Citizen Developers

    7 Steps to Unleashing Your Citizen Developers

    As digital transformation accelerates, organizations are searching for ways to enable all their employees—not just IT, development or DevOps teams—to design, build, iterate and launch new processes and applications as per their requirements. This democratizing approach is called citizen development—where business users are empowered to create their own processes and apps with only minimal supervision from IT, ultimately relieving them from IT backlogs. 

    How to Get Started with Citizen Development

    Running a citizen development program doesn’t mean relegating IT to the sidelines. Citizen developers can often be prone to mistakes due to their lack of programming background. Limited skills may also result in creating a faulty app or unknowingly developing one that resembles existing software that serves the same purpose.

    Thus, citizen development calls for a new relational approach that’s founded on transparency, trust and dialogue between IT specialists and non-IT employees. 

    As a business leader, you’re in the best position to initiate such a program. Here are the steps you can take to get you started: 

    1. Identify citizen development potential

    You can issue surveys across departments or meet with division heads to understand who is using forms of shadow IT or already using citizen development tools, what they’re using these for and the number of users of these apps. Your findings can help you assess which departments have the most citizen developer candidates.

    Also, determine your company’s backlog of IT requests and current IT pain points. Knowing the pent-up demand will give you an idea of what issues citizen developers can seek to resolve.

    2. Set clear goals

    Communicate what citizen development aims to accomplish for your organization. Identify the apps you intend to create, the mode of deployment, the role of citizen developers and which departments will benefit.

    3. Get support from IT and fellow business leaders

    Find partners in the IT team and among other managers who can help champion your vision for citizen development. 

    First, approach the potential managers who will be collaborating with you in this cause. Getting their support early can aid you in establishing a more well-rounded vision and avoiding any conflicts down the road. By helping them understand how it will actually boost their department’s workflows instead of delaying internal tasks, you’d be able to muster credibility for your proposal.

    Meanwhile, assure your IT team that there’ll be a clear delineation of responsibilities between citizen developers and IT personnel. Employees will undergo self-directed and group training before being allowed to access a development environment. The software development life cycle will also be documented to make citizen developers aware of the process and necessary requirements for submitting their ideas. Moreover, IT developers will still be in charge of providing documentation, evaluating ideas and offering technical guidance with regular check-ins.

    4. Shortlist low-code/no-code platforms according to your business needs

    It would be best to look for low-code platform providers, schedule demos and invite IT and business unit leaders during dedicated sessions. They can compare feature sets and appraise learning curves with you. 

    5. Lay down a governance plan

    A governance plan ensures that data security best practices are in place and that IT assistance is well-defined in your citizen development program. Such a plan should cover:

    • The evaluation process for admitting projects into the citizen developer backlog or IT backlog
    • Standard compliance and security requirements for any project accepted for citizen development
    • Standard workflow protocols including testing, validation, audit and integration
    • What instances will require IT involvement

    6. Get senior management buy-in

    You’ll need to communicate your intentions with your senior executives and prepare to formally present your citizen development plan. 

    • Establish the rationale behind the plan. Compare internal metrics with industry stats showing the current need for citizen developers. Cite success stories or case studies.
    • Share internal figures pointing to the current IT backlog as well as results of surveys and discussions with employees and fellow managers.
    • Calculate and show your company’s projected one- to five-year ROI for using low-code/no-code platforms for citizen development.
    • Introduce your proposed governance plan and pilot program.

    7. Start training

    The citizen developers should be given time to learn the selected low-code/no-code platform. You can later pick a use case to pilot the tool. Identify your expectations and criteria to measure the success of the project.

  • Why the Built World Needs Standard APIs

    Why the Built World Needs Standard APIs

    Lately, new ESG initiatives have come front-and-center as companies seek to contextualize and limit their business’s impact on the environment. This is especially true for the built world—a term that refers to the human-made environment that provides the setting for human activity, including homes, buildings, zoning, streets, sidewalks, open spaces, transportation options and more—where monitoring energy efficiencies is becoming more commonplace and even required by law. For example, a New York City law now requires buildings of a certain size to post an energy-efficiency score at their entrances. Yet, calculating such a score isn’t that straightforward—there’s a lot of legacy technology in use within most large commercial and residential buildings, and pulling data from these systems is notoriously difficult.

    A building manager may seek greater visibility into these systems to not only determine a building’s energy score, but to program optimizations, inform building security or enact new digitization. But the answer isn’t to hastily rip out and upgrade old hardware—old equipment like AC units and elevators were built to last 50 years or more and could be functioning seamlessly. Instead, this is another area where REST APIs are set to accelerate by uniting legacy integration software and disparate hardware with a standard layer.

    I recently met with Shaun Cooley, CEO and founder of Mapped. According to Cooley, API-driven standards for built environments could open up transparency into hardware component behaviors and the interrelationships between systems within a building. Below, we’ll briefly consider the history of building protocols and look to standards like Brick Schema that aim to unite legacy and modern physical infrastructure. We’ll consider the competitive advantage APIs bring to the built world and how increasing data accessibility could assist operations.

    The State of Physical Building Digital Protocols

    The built world consists of various digital communications standards. Most buildings have many older on-premises protocols for lighting, HVAC, elevators and other systems. For example, many elevators and fire safety systems were installed by systems integrators in the 1970s and adopted connections using Modbus, a communication protocol based on serial connections. BACnet is also commonly used to control HVAC systems and is a step forward from Modbus in that it can more easily connect to IP networks.

    Fast-forward a few decades to the dawn of the cloud; many companies overlaid sensors onto these old systems, explained Cooley. These power-over-ethernet (PoE) or battery-powered systems relay data immediately to the cloud and often speak in proprietary protocols. A single commercial building could easily be juggling a bundle of these various communication protocols, all originating from installations that occurred at different time periods. These nuances mean that you are “constantly dealing with chaos across your portfolio,” Cooley said. There’s so much data, but getting it normalized and usable is very challenging, he said. One must integrate with many sensors and protocols, which he describes as “the dirty plumbing” that no one wants to build.

    There’s bound to be differentiation from building to building, too, which could place a further strain on managing multiple building operations. Without a window into building data, it isn’t easy to know things like the current occupancy of the lobby or how occupancy affects energy consumption. Unless managers can connect the dots between systems, it’s impossible to understand the relationships between components.

    Making a Data Graph for a Building

    For example, take an AC system in a commercial building. Such a unit isn’t as simple as a single-family home’s typical thermostat and furnace. It’s often a mix of a rooftop chilling unit, pipes, pumps and a VAV damper that controls the air. While protocols are good at describing how individual components are performing, the composition of components is really what defines a building’s system and its efficiency, said Cooley.

    According to Cooley, instead of adopting a vertical data schema, buildings require a graph data model to adequately represent hardware interconnections. This is why he’s rallying behind Brick Schema, an open source uniform metadata schema for buildings. Instead of a vertical data schema, Brick Schema is built on a graph data model, which enables more descriptive relationships in a system.

    End Benefits

    Pulling unstructured data from 20 different data lakes into a clean API could allow easier access to new solutions. “We want to make it very simple to build applications for these sorts of environments,” said Cooley. Typically, system integrators must reverse engineer and connect to legacy building hardware, which can become very expensive very quickly, he said. He recommended using a sandbox based on open standards that can easily be rolled out to any building to reduce those hurdles. A more consumable layer with common endpoints could increase developer usability when creating innovative building applications.

    Similar to how Twilio made SMS easy, Cooley said he hopes for a similar proliferation in the built world. Many applications could be built with such an abstraction layer. For example, managers could better understand energy usage to reduce consumption, meet regulations and save money. Or, such an abstraction layer could inform predictive maintenance to create automated alerts before failures occur. There are also plenty of ways to improve occupant experience or intelligently optimize the lighting and temperature in a space.

    “Entirely new business models and concepts emerge that we hadn’t considered previously,” said Cooley. For example, he described a “tailgating app” that uses Brick Schema for a security use case. The app prevents building occupants from letting other people “tailgate” into the building behind them after someone swipes their badge. To do so, the app interfaces with many separate building systems (the elevator system, surveillance system, telepresence systems and other sensors) to ensure the number of people in the building matches the number of occupants that swiped in. A lingua franca helps to connect the disparate hardware involved.

    The Future of Building Automation

    This is by no means the first attempt to standardize building data. For example, the Green Button Initiative provides a standard API through which to download utility use data for electricity, gas and water and share it with solution providers. However, according to Cooley, this information only goes so far. Building owners will require more contextual data on-site.

    For example, perhaps a building’s window glazing is causing specific rooms to overheat in the sunlight. Thermal sensors would spot this condition, but bulk energy consumption readings wouldn’t ascertain the root cause. Access to real-time granular data such as current occupancy count is also necessary for developing on-site applications that better refine exactly how human involvement impacts energy consumption.

    Of course, as building systems become more intelligent, there is the growing possibility of privacy infringement. For example, systems that use facial monitoring and recognition could end up storing personally identifiable information. In that case, you “need to give data owners the control to decide what applications can’t or can’t access PII,” said Cooley.

    While this field has many read-only applications, Cooley predicts future write operations will enable more automation with building hardware. This could allow applying ML/AI to anticipate elevator floor calls. Or, a predictive system could cool a room only when a meeting is scheduled. When such data is readily accessible and available for developers, it presents many innovative opportunities to optimize and interact with the built world.

  • Ukraine Asks for DNS Censorship | Ukraine Snapchat Staff Danger | #BoycottKaspersky?

    Ukraine Asks for DNS Censorship | Ukraine Snapchat Staff Danger | #BoycottKaspersky?

    Welcome to Ukraine Week here at The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Censoring the Russian internet, Snap fears for hundreds of Ukrainian employees, and Eugene Kaspersky acts like a ****.

    1. ICANN, but IWONT

    First up this week: Ukraine has asked ICANN to drop Russia from the DNS. Andrii Nabok, the Ukrainian representative of ICANN’s Governmental Advisory Committee argues a DNS blockage would “help users seek for reliable information in alternative domain zones, preventing propaganda and disinformation.”

    Given today’s confirmation that Muscovite K12 students had been arrested for laying flowers at the Ukrainian embassy, this goal seems all the more laudable. But frankly, a moment’s thought says it’s a bad idea.

    Analysis: “The net interprets censorship as damage and routes around it”

    John Gilmore was right. Such a move would inevitably fail. And there’s a real risk of undesirable, unintended consequences.

    Kat Bouza and Noah Shachtman: Ukraine Pushes to Unplug Russia From the Internet

    Ukraine’s request to the Internet Corporation for Assigned Names and Numbers (ICANN) seeks to revoke domains issued in Russia and shut down primary Domain Name System (DNS) servers in the country. [It] would send a strong message to a regime pumping out digital propaganda.
    …
    The DNS root zone is a crucial element of the overall functionality of the internet, responsible for handling queries to top-level domains — such as .com, and country-specific domains like Russia’s .ru. Removing Russia’s access to this cluster of servers would prevent Russian internet-service providers from communicating.
    …
    But … the unprecedented request has the potential to do more harm than good. … Representatives for ICANN … declined to comment.


    But the request is pretty naïve, thinks this Anonymous Coward:

    All they would have to do is get the ISPs to add a zone to their DNS that says “ru. IN NS x.x.x.x” and then for all their users, any requests for a .ru domain would be directed to x.x.x.x

    OK, the rest of the world would miss out, but I doubt that they would care.


    Is there a better way? ArmoredDragon breathes fire:

    A better way … is to ask western certificate authorities to revoke all [Russian] certificates. Then ask the major OS and browser vendors to remove any CAs that don’t comply.

    That would really **** with them because there’s nothing [Russia] can do about that. And it would even **** with Russia’s ability to do business with Chinese companies and Chinese customers.

    2. Fear for 300 Ukraine Employees at Snap

    Snap, Inc.—formerly Snapchat—owns the Ukrainian company that created the technology used in the real-time video shenanigans behind “I’m not a cat.” It has hundreds of employees in Kyiv and Odesa.

    Analysis: Solidarity doesn’t Stop Wars, but Sanctions Might

    This very human DevOps story is but a footnote to the wider picture of tech companies acting to echo Western governments’ sanctions. It’ll cause us a little pain, but that’s nothing compared to the suffering felt by Ukrainians. And it’ll be worthwhile if it shortens the war.

    J. Clara Chan: Three hundred Snap employees are from Ukraine

    In a public note, … Snap — the parent company of Snapchat — said … that 300 of Snap’s “most creative and talented team members” are from Ukraine, … the birthplace of Looksery, the augmented reality platform that Snap acquired in 2015. … Snap said it has pledged over $15 million in humanitarian aid to support Ukraine. … The company is also providing emergency assistance to employees who need help safely relocating.
    …
    “We stand in solidarity with our Ukrainian team members and the people of Ukraine. … This is a devastating conflict with far-reaching consequences. … It is a direct threat to many of our team members and their families.
    …
    “Over many years working with our Ukrainian colleagues and friends, we have gotten to know the inventiveness, strength, and resilience of the Ukrainian people. … We will continue to work tirelessly to help our Ukrainian team members and their families, support our Snapchat community, and determine how we can help make positive contributions to the immense humanitarian efforts underway.”


    It’s bang on trend, reports Corinne Reichert:

    Snapchat has followed suit after Facebook, Twitter and YouTube began pausing ads on Friday, saying it has now stopped all advertising running in Russia, Ukraine and Belarus following the Russian invasion of Ukraine. … The Snapchat app remains live in Ukraine, Russia and Belarus, [but] Snap is monitoring the platform for misinformation or other misuse.
    …
    Apple has also halted sales of its products in Russia, as well as online transactions, Apple Pay and some Apple Maps features. Google [is] temporarily disabling some live Google Maps features, adding an SOS alert to Search and blocking Russian state-controlled media. It said Google Pay “may become unavailable.”


    But don’t hang up on Dade “+++ATH” Hayes: [ask your parents]

    In terms of any financial sacrifice from the foregone advertising opportunities, it isn’t clear that all that much is at stake for Snap. … While the company’s stance on the Russia-Ukraine situation clear and emphatic, it is also an easier one for for Snap to take than for many of its tech rivals.

    3. Yevgeny Valentinovich ‘Eugene’ Kaspersky has Chosen the Side of the Oppressor

    The figurehead eponym of AO Kaspersky Lab is being publicly shamed for comments he made about the war in Ukraine. In stark contrast to Snap’s statement, he is accused of overt neutrality, minimizing the war’s severity—and even of shoehorning in some marketing.

    Analysis: #BoycottKaspersky

    Desmond Tutu was right. But, while it’s tempting to “cancel” Eugene, dial down the emotion and think instead about your security posture. If you use Kaspersky products internally, what risks are you exposing your organization to? How might the Russian government exert pressure on the company to compromise your network?

    James Coker: Eugene Kaspersky’s Statement Provokes Controversy

    Cybersecurity industry veteran Eugene Kaspersky has provoked a strong reaction from leading figures in the sector. … Kaspersky, CEO of the Russian-headquartered IT security vendor of the same name, broke his silence on the conflict:
    …
    “We welcome the start of negotiations to resolve the current situation in Ukraine and hope that they will lead to a cessation of hostilities and a compromise. We believe that peaceful dialogue is the only possible instrument for resolving conflicts. War isn’t good for anyone. … The main thing we can do in this situation is provide uninterrupted functioning of our products and services.”
    …
    His description of the conflict as a “situation” and apparent attempt to advertise his firm led to a number of furious responses. … Following Kaspersky’s tweet, the hashtag #BoycottKaspersky appeared.


    With a balanced view, it’s Nick Farrell:

    Kaspersky sits on the fence … in Russia it is not a good idea to have a view. [But] whoever is advising Kaspersky on PR might need to have a rethink.
    …
    After all a compromise is [not] always possible when one side is firing missiles into residential areas. If he applied the same premise with ransomware, he would be suggesting, … “It is better that you talk to the people who are holding your servers hostage.” … How much is Kaspersky, the company, influenced by the Russian government?


    Does your shop use Kaspersky? Nick Lange cuts to the chase:

    I would like to remind all readers that, in case of war, … software with access to companies and the capacity to be updated worldwide in matter of hours at the same time is a high class target to get forced to cooperate by a autocratic government.

    The Moral of the Story: If an elephant has its foot on the tail of a mouse and you say that you are neutral, the mouse will not appreciate your neutrality.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Brandon Morales (via Unsplash; leveled and cropped)

  • Multi-Cloud Computing is a Major IT Headache

    Multi-Cloud Computing is a Major IT Headache

    A CloudBolt Software survey of 500 senior IT, DevOps, security and finance leaders found 79% are struggling under the weight of managing multiple cloud computing environments.

    The survey from CloudBolt Software, a provider of a cloud management platform, found specifically that more than three-quarters of respondents (78%) said they have too many cloud tools throughout their enterprise, and 80% struggled to achieve comprehensive visibility into cloud usage and spending. A total of 80% also noted that their current approach to cloud computing created new security vulnerabilities.

    A full 88% said they need a “manager of managers” that would enable them to unify the various silos that have multiplied across their IT environment.

    Nevertheless, 78% of respondents said that moving to the cloud enabled them to achieve cost savings compared to running applications in an on-premises IT environment.

    CloudBolt Software CEO Jeff Kukowski said the issue is not so much that IT organizations regret shifting workloads to the cloud; instead, the issue is finding a way to manage multiple clouds, each with their own set of tools and frameworks that need to be mastered.

    It’s not clear whether organizations are deliberately employing multiple clouds or if, because of simple inertia, they have found themselves managing multiple cloud platforms because of decisions made by various development teams. Some IT organizations, for example, employ multiple clouds because they are concerned about either becoming locked into a specific cloud computing service or whether an outage might take all their applications offline at the same time. Others are simply trying to take advantage of services that are better provided by one vendor than another.

    Regardless of how IT organizations found themselves managing multiple clouds, the total cost of IT rises as each new platform is added to an IT environment. CloudBolt Software is making a case for an IT framework that provides a layer of abstraction through which the management of multiple clouds and on-premises IT environments can be unified. It is more a question of time and degree to which IT organizations will eventually consolidate the management of disparate IT environments under a single control plane that provides the foundation for true hybrid cloud computing, said Kukowski.

    There are, of course, a few organizations that have standardized on a single cloud computing platform. The degree to which those organizations can maintain that standard will naturally vary as, for example, new workloads that may be optimized for a specific cloud environment are built or as companies acquire other organizations that are running workloads on other cloud platforms. In many of those cases, organizations discover that the cloud services invoked expose a range of proprietary application programming interfaces (APIs) and disparate virtual machines that make migrating workloads a major challenge.

    Like it or not, most organizations will be managing multiple IT environments for the foreseeable future. The only thing that is uncertain is the volume of workloads that might be running on any one of those platforms at any given time.

  • SQL Server MDF to NDF Distribution

    SQL Server MDF to NDF Distribution

    Do you have massive MDF files on your database? Have you noticed that your SQL Server disk stall metrics for these data files are higher than the storage latency metrics exhibited on the underlying operating system? It could be that your SQL Server data files are being hammered too hard and you don’t have enough data files to help the SQL Server storage engine distribute the load. We do this for tempdb, right? Let’s do this for our user databases as well. It’s easy for a brand-new database. But existing databases may be out of control with a single data file. Let me show you how to adjust this for existing databases without an outage!

    I’ll be taking the SQL Server database generated by the HammerDB benchmark, appropriately named tpcc_test. It’s just a backed-up-and-restored copy of the (appropriately named) database tpcc_single to represent a single MDF file present. 

    I did a restore onto the F: drive of this server. The MDF size is rather substantial at 420GB. The log size is inconsequential for the purposes of this task.

     

    Here’s the interesting part. Take a look at the current file system size versus the internal fill size. Record the internal fill size, as that’s what we’ll be using to help with some math shortly.

    Now, how many files do you need? Here’s my standard DBA response—it depends. For the purposes of this test, I’m going to add seven NDF data files to complement the primary MDF. Your mileage may vary based on your workload. 

    How large do these files need to be? Take the internal fill size on the MDF, divide by the number of data files you want in total and round up to the nearest megabyte. If the database is active with a lot of data being added, you might want to add a bit more just to have it balance by the time we’re done with this task.

    SELECT f.name AS [File Name] , f.physical_name AS [Physical Name], 

    CAST((f.size/128.0) AS DECIMAL(15,2)) AS [Total Size in MB],

    CAST(f.size/128.0 – CAST(FILEPROPERTY(f.name, ‘SpaceUsed’) AS int)/128.0 AS DECIMAL(15,2)) 

    AS [Available Space In MB], f.[file_id], fg.name AS [Filegroup Name],

    f.is_percent_growth, f.growth, fg.is_default, fg.is_read_only, 

    fg.is_autogrow_all_files

    FROM sys.database_files AS f WITH (NOLOCK) 

    LEFT OUTER JOIN sys.filegroups AS fg WITH (NOLOCK)

    ON f.data_space_id = fg.data_space_id

    ORDER BY f.[file_id] OPTION (RECOMPILE);

    Now is the time to determine if these should be placed on the same disk or if they should be distributed across more disks. I’m doing that on this server to leverage the disk controller queues to more widely distribute the storage activity and see better overall performance when under pressure. I’ve attached three more virtual disks to this virtual machine, and the four are spread on the four disk controllers on this virtual machine. All disks are formatted with a 64KB NTFS allocation unit size with the large FRS flag enabled. Let’s place two of these files on each disk with the fourth holding the last NDF with the MDF. 

     

    Here’s a trick: I set the maximum file size of each of the new NDF files to be the percentage of the current main file space consumed. 

    Now, we’re going to use a little-known command to empty the MDF file. It’ll drain the file completely, but since we capped the file growth of the NDF files that we attached to limit their growth rate, this command will run until we have filled the NDFs, then fail. It will take longer to perform this operation, but it keeps the database online while it runs. You might have a bit of a performance hit from the CPU and I/O impact of this running process, so it’s important to think about timing when running this operation.

    You can watch the process work with the internal used space query listed above; the primary MDF is draining while the other NDF files are slowly filling up.

    Again, it takes time for this process to finish. When it finally ‘completes’, the EMPTYFILE command will fail due to maximum file size limit on the NDF files.

    FYI—Index optimization routines can cause a circular block with this process that I have encountered twice while running this process, so keep an eye out if you see this occur.

    Now, your internal data consumed space rates are almost identical. 

    Verify the autogrow rates are now the same between the data files. Remove the file growth limit on the NDF files. 

    Perform a one-time shrink of the primary MDF file to shrink it down to where it is the same size as the others.

    It will most likely be slightly out of balance. SQL Server does a pretty good job with the round robin algorithm for internal file fill rates, and it will finish balancing and then round robin filling internally as you continue to add data through normal usage. If you need to increase the size on some of the files so they match, go for it, and SQL Server will fill accordingly so it finally balances.

    You might also check if you need to enable autogrow all files at the same rate. This could mean that the database users might need to be punted from the database to enable the change.  Do this during a maintenance window.

    Sample your SQL Server disk stall rates and see what different you experience once this goes live.

    I hope this helps you improve the operational efficiency of your SQL Server database data files, and you get better performance as a result. Let me know how this works for you!

    Update: If you encounter an error like the following, just shrink the main MDF file down and repeat the emptyfile operation.

  • Akamai: Buying Linode | Firefox: Not OK | Gone: Google Vaccine Mandate

    Akamai: Buying Linode | Firefox: Not OK | Gone: Google Vaccine Mandate

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Linode gets bought by Akamai, Firefox market share is “measly,” and Google brings staff back to the office.

    1. Akamai + Aker = ‘Synergy’

    First up this week: Why is Akamai buying Linode? Whatever the reason, it’s a big payday for its solitary shareholder: Not far off a billion dollars.

    Analysis: There goes the neighborhood?

    The 100 lb gorilla of edge computing and CDNs is promising not to mess with Linode’s winning open source cloud formula: No change, steady as she goes, etcetera. But how many times have we heard that before?

    Here’s local scribbler Paige Gross: Linode’s $900M acquisition by Akamai is a ‘game changer’

    A household name in the Philly tech scene … CEO Christopher Aker founded the company in 2003, and it’s been bootstrapped ever since, growing to about 250 employees. … Aker has owned 100% of Linode since he founded it.
    …
    Aker said the deal brings the company closer to solving evolving challenges “as cloud services become all-encompassing, including compute, storage, security and delivery from core to edge. … We’ve been talking about ‘alternative cloud’ — alternative to the big guy — and now we’ve sort of validated ourself in this market.”
    …
    The Old City company maintains “well over a million accounts” but has anywhere around 150,000 active users of its platform at any particular time. Linode’s HQ, the bank building at Third and Arch Streets, remains. … For clients and Linode employees, there won’t be too much noticeable change [Linode] says.


    Why does Akamai want Linode? Jonathan Greig asked the CEO:

    Akamai CEO Tom Leighton [explained] that Linode has great customer support and is already in 11 locations, which Akamai is going to “dramatically” expand. … Leighton also noted the September 2021 acquisition of Israel-based Guardicore, a cybersecurity company that offers a micro-segmentation solution to reduce the potential attack surface of corporate networks, secure applications, and meet compliance standards.
    …
    According to Leighton, the company is expecting the cloud compute category — which includes edge applications, its net storage business, and Linode — to reach “well over half a billion dollars in 2023. … We were pioneers in edge computing and now we’re taking a big step forward in cloud computing with Linode.”


    But here’s a worried-sounding zoid.com:

    Well good for them but I hope [Akamai] don’t screw it up. Linode is a great hosting company.

    2. Firefox isn’t OK

    Last week, a journalist innocently asked, “Is Firefox OK?” And people lost their minds.

    Analysis: No, not OK—it’s a big problem for DevOps and the web.

    We need Firefox and Gecko. A Chromium monoculture is bad for the web and bad for DevOps. (Before you ask: No, the existence of WebKit doesn’t change things, thanks to Apple’s ridiculous policies). Much as I tried to say something nice about Firefox last month, its market share is, frankly, pathetic.

    Matt Burgess: Is Firefox OK?

    In the two decades since Firefox launched from the shadows of Netscape … the browser has slid to less than 4 percent of the market—on mobile it’s a measly half a percent. … Its fate also has larger implications for the web as a whole.
    …
    Each year Google pays Mozilla hundreds of millions of dollars in royalties. … In its 2020 financial results … Mozilla listed its total revenue as $496 million. … The Google-Mozilla deal was last renewed in 2020 and is expected to expire in 2023. … Mozilla and Firefox acknowledge that for its long-term future it needs to diversify the ways it makes money.
    …
    Firefox still matters: … The browser market is dominated by Google’s Chromium codebase and its underlying browser engine, Blink. … Microsoft’s Edge Browser, Brave, Vivaldi, and Opera all use adapted versions of Chromium. Apple [has] its WebKit browser engine [but] other than that, Firefox’s Gecko browser engine is the only alternative.


    Firefox, how do we love thee? Let not_count_zero count the ways:

    I still use Firefox because:
    a) I remember Internet Explorer and the standards wars. …
    b) I don’t trust Google. …
    c) Most sites work well.
    …
    I do have questions though. … They’re currently getting around a half a billion‽ What are they doing with it? … This seems really off—really, really off.


    But heed a deeply worried Thom Holwerda:

    The decline and potential demise of Firefox is a massive problem that everybody seems to be kind of tiptoeing around—too afraid to acknowledge that if Firefox were indeed to disappear, we’d be royally screwed. We’d end up right back where we started 20 years ago, with Chrome being the new IE6.
    …
    The situation is especially dire for … Linux users, developers, and distribution makers. … Gnome Browser or KDE’s Falkon can barely be taken seriously, and … are based on Apple’s WebKit, which isn’t a great position to be in.

    3. Google’s Return to Work Plan Drops Vaccine Mandate

    Google is planning “celebrations” to welcome back employees after being fully remote. And in practice—unlike at IBM—this doesn’t mean a vaccine mandate.

    Analysis: Vocal minority wins—or do they?

    It was just three months ago that Google said it “firmly stands behind our vaccination policy.” What changed? It’s unlikely to have been due to a tiny minority of staff publishing a manifesto.

    Jennifer Elias: Google relaxes mandates

    The company will no longer require vaccination as a condition of employment … as it prepares to bring workers back to the office … at least three days a week for a “hybrid” work model. … The company [had previously] told employees that they must comply with vaccine policies or they’d face loss of pay and eventually loss of employment.
    …
    According to Google spokesperson Lora Lee Erickson … the company dropped the requirement … after removing the Jan. 18 deadline it had set for employees to either get vaccinated or get exemption approval. She declined to provide further details on the policy or the reasons for the reversal.
    …
    Google Real Estate and Workplace Services VP David Radcliffe [said Google] is preparing to begin its 30-day transition period to the hybrid work week if conditions continue to improve. He said his team is planning “celebrations” to welcome back employees. … Unvaccinated employees who are approved to enter offices will still need to follow additional protocols, including testing and wearing a mask.


    It’s too simplistic to say the anti-mandate brigade are also anti-vaxxers. For example, raxxorrax:

    I am vaccinated and HR knows this. … But if they officially demanded a certificate, I think I would have called it quits. Many people don’t have that option [but] there are consequences for such unreasonable demands.
    …
    I understand a mandate for vaccinations in certain occupations relating to health. It is something you have to personally accept if you want to work in the field.


    Although a few others are way over at the end of the bell curve. Greg Jinkerson:

    Don’t get excited, [Google is] still evil and stupid. … Now they’re backing down for some reason, [but] this is barely anything notable as far as a rollback of restrictions. [It] is not any kind of encouraging news.

    The Moral of the Story: Failure is the foundation of success—and the means by which it is achieved.


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Aleksey Kuprikov (via Unsplash; leveled and cropped)

  • Merging Secrets Management and Configuration

    Merging Secrets Management and Configuration

    Fresh from picking up $5.25 million in funding, CloudTruth CEO Greg Arnette talks with Mike Vizard on this episode of the View With Vizard about why configuration and secrets management need to converge. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Mike Vizard: Thanks for the throw. We’re here with Greg Arnette, who’s the CEO for CloudTruth, they just raised $5.25 million to help us with these configuration issues that seem to plague us. Greg, welcome to the show.

    Greg Arnette: Thank you. It’s great to be here, and thanks for the opportunity to tell your audience about CloudTruth.

    Mike Vizard: So, what is the configuration problem, and why does it not seem to wanna go away? It’s been around for a while, things appear to be getting worse, and what’s to be done about it?

    Greg Arnette: Exactly. So, that ties into the history of founding this company. Both myself and my Co-founder were prior CTOs and DevOps leaders for several cloud-based SaaS companies, and we saw that our DevOps teams were continuing to build internal tools to address issues around configuration sprawl and complexity. And these tools tend to be the weak links in terms of solid deployments, good up time, good security, and basically, slows teams down.

    So, the history of kind configuration sprawl and what we see as the challenges is sort of driven by a number of macro trends—first, the fast rise of Kubernetes; everyone wants to get on the Kubernetes bandwagon. That introduces new complexities around configuration management, new sets of tools that haven’t been sort of well adopted inside of DevOps shops. Another trend is the breakup of monoliths to microservices adds lots of new dimensions on configuration complexity. And then there are the traditional needs around provisioning infrastructure, configuring your apps, and managing secrets are the sort of legacy challenges around configuration management. And as the cloud gets more mature and with more capabilities, configuration is not getting easier, but getting more difficult.

    So, CloudTruth is here to address those concerns. We heard, during our product market fit research where I interviewed over 500 cloud and DevOps leaders on their challenges managing configuration, that this over reliance upon tribal knowledge in terms of how a system is configured and why it’s configured a certain way is just held in key team members’ heads, and that’s not a very durable strategy for going forward or for on boarding new folks. So, there’s an element of CloudTruth that provides collaboration and sharing around configuration settings and context to help reduce that need of, or that sort of burden of the cognitive load to keep track of how are things configured, where is the data, how can I change it, what changed recently—that type of thing.

    Mike Vizard: You guys also acquired a company in this process in the secrets management space, so where does configuration and secrets management converge and how do we think about that?

    Greg Arnette: That’s a great question. So, we acquired Tuono, we’re thrilled to bring in the Tuono team, including Jesse St. Laurent, who was the CTO, who joins us as our Chief Product Officer. Jim King, Mike Healey, Mike Stack all joined us, they were the founding engineers at Tuono.

    And what we did was, we took the Tuono secret management engine, which was cloud native and we’ve now included that in the CloudTruth platform which rounds out our offering. So, CloudTruth, while it is also a configuration data hub to synchronize your configuration settings from all these multiple tools is also itself a parameter store and secret store that customers can use if they don’t already have existing parameter stores or secret stores in their environment.

    Mike Vizard: And in that context, what does cloud native mean? Because some will people say, you know, it runs in the cloud; other people will say that it only runs on Kubernetes, it’s optimized for microservices and containers. Or is there some middle ground there and what do we think about cloud native—what context are we using that phrase?

    Greg Arnette: Yeah, when we use cloud native, we mean or refer to the capabilities that are provided as part of core services at Amazon, Azure, and Google. So, an example is, Amazon themselves provide a parameter store, they call it AWS Parameter Store. Google and Azure provide the same kind of internal capabilities. Customers can also bring their own parameter store, like run something like Console on top of the cloud or using Vault sometimes as a general-purpose parameter store.

    So, the cloud native offerings like AWS Parameter Store, Secret Manager, and the equivalent on the other clouds are things that customers can use, they have different price points. We provide a layer of management and visibility and observability to all that config data stored inside of all these different systems.

    Mike Vizard: And when you talk about unifying configuration, are we replacing Terraform and CloudFormation, or are we just finding some way to layer some form of abstraction around them that makes the whole process easier to manage? Walk me through that a little bit.

    Greg Arnette: Yeah, you know, we’re not replacing Terraform or CloudFormation. We’re designed to coexist with the customers’ existing investments and their configuration tooling. So, whether it’s provisioning tools like Terraform, CloudFormation, Pulumi, or app config tools like Ansible, Puppet, Chef, Saltstack, or secret tools like Vault or the cloud native versions of those capabilities. We coexist and become a metadata wrapper around those different tools.

    Now, if customers don’t have some of those capabilities, we have functionality in our platform that can fill the gap, but more and more customers already have these systems in place. They’re not looking to rip everything out and replace it, but they’re looking to address these issues around configuration sprawl that leads to a misconfiguration causing unplanned down time or a security incident.

    Mike Vizard: We have been talking about DevOps and DevSecOps forever, and the idea has always been that we’re shifting more responsibility for the IT environment to the left of the developer. Sometimes they like that, sometimes they don’t.

    But I wonder, are we not approaching some sort of concern or maybe a backlash where folks are saying, “Hey, you know what? This isn’t really working. We have all this misconfiguration out there, we’re maybe running faster, but things are less secure, and we have more risk than ever.” So, is there a balance to be struck, or what’s your sense of where are we on this journey?

    Greg Arnette: That’s a very interesting question. This is something that we hear all the time in our outreach to our customer audience is what their journey looks like for adopting shift left or GitOps types of operating principles. We’ve seen a number of patterns emerge over our hundreds of interviews. Specifically, most teams do want to give developers more capabilities to do things themselves and reduce that burden on the Ops team, but they still want Ops or DevOps teams to have the overall sort of judgment and enforce the guardrails that were put in place by the security and compliance teams and by the other teams that are sort of deciding what are the best practices.

    So, with CloudTruth, we’re kinda serving both audiences in a purposeful way. You have centralized control and visibility that DevOps wants. They wanna build and enforce lockdowns, enforce default settings that can only be overridden with a permission or an override that’s allowed as part of a workflow. But you also provide capabilities for core developers to manage the config for their own environments and to suggest configuration changes that then can be adopted more system wide.

    So, we’re serving that duality that exists today. We’re gonna let the customer decide on where they ultimately land about developing shift left principles and moving that direction. But we see a lot of interest in that, and it helps to reduce that—you know, again, that cognitive load and that context switching on the DevOps professionals. Because so many times, they’re being bothered by other folks and other developer teams, like, “What’s the setting for this Redis cluster? Why is our Mongo configured this way? How do I tune my elastic search test cluster to match production?”

    That information will all be self-serviceable and findable inside the CloudTruth platform. And our role based access control permissioning system allows view only, read only, read/write access to the appropriate areas, and then DevOps teams can sort of wall off the production systems from other people having chances of changing those settings.

    Mike Vizard: Mm-hmm. What is the role of the security team as we go forward? It feels like, if we shift everything left to the developers, what are those guys doing?

    Greg Arnette: They still need to be involved in terms of ensuring that no bad information gets in and no good information gets out. So, we provide a number of views into configuration data that are helpful to security teams. First is, what changed most recently in terms of your compliance management reports for SOC 2 and other requirements and keeping track of changes. That’s really hard in a dynamic environment, especially cloud-based where you have microservices firing left and right, coming up and down. The old traditional CMDBs that were popular in the on prem world don’t really fit well in the new way that we’re using the cloud.

    And so, CloudTruth is a self-documenting change management control system that is, behind the scenes, keeping track of all the version settings of every configuration value that we’re monitoring, and then we provide views into that data that can be consumed by the security or compliance teams to get better insights for their needs without having to bother the DevOps teams.

    Mike Vizard: Do you feel like the bad people, otherwise known as cyber criminals, are getting better at scanning for misconfigurations and looking for these vulnerabilities to exploit? And we hear a lot about software supply chains these days—it seems like, in a lot of cases, the root cause of the problem is just misconfigurations.

    Greg Arnette: It’s true. We’ve found, in our own research, that 75 percent of unplanned down time or security incident was caused by a misconfiguration when you ultimately read the root cause analysis and do all the internal tracing.

    So, what we wanna provide are the best practices as early as possible in the software development life cycle process to implement good config hygiene. And then secondary to that is, once config is out there in the wild, provide monitoring and insight into how it could affect security vulnerabilities or security posture. Since everything these days is defined as infrastructure as code, it’s all about analyzing all the different locations where config values are stored, making sure those are secure and locked down, and then being able to use any kind of pattern recognition to understand where certain areas can be vulnerable to being taken advantage of by the nefarious factors out there in the world.

    Mike Vizard: Do you think we’ll get to the point where we can use automation to kinda get ourselves out of this mess? We have APIs and CLIs and everything else that’s out there—shouldn’t we, at some point, have enough intelligence in the work flows to say, “Hey, this thing you’re about to deploy is misconfigured, so don’t do it”?

    Greg Arnette: That’s part of our goals down the road is, we have a very thoughtful strategy how we wanna launch CloudTruth as a full configuration data management platform. So, the first goal is to get inserted into a company’s work flows where we have access to the data and can provide value with reports and work flows. The second goal is then, once we’re now managing this data on behalf of the customer, to apply AI and ML, looking for patterns, recommending optimizations, best practices, vetting what we see from a customer perspective against best practices being published by other standards bodies that are looking at this from different perspectives.

    One goal of CloudTruth is to be that configuration data layer management system that we think most companies using the cloud need these days.

    Mike Vizard: We also hear a lot about artificial intelligence—will that get applied to this space? Is there any scenario where we’ll just have a bunch of machine learning algorithms running around, figuring out what’s going on?

    Greg Arnette: We firmly believe that that is definitely gonna be happening a few years down the road. I think the maturity model is just getting started. The first act in getting that up and running is getting access to the data for trending the models and analyzing the trending results, optimizing the model. So, a full observe-orientate-decide-act OODA loop is involved here in terms of making sure those models are accurate, but we think that’s gonna be a big benefit in what we can provide down the road.

    Mike Vizard: So, what’s your best advice to folks? What should they be focusing on today to get to that nirvana tomorrow? Is there same way I should be organized, is there some way I should be talking to my developers? What do you think?

    Greg Arnette: There’s a couple themes that come to mind. The first is—which sounds almost obvious these days—is make sure you are able to do infrastructure as code ideas at all levels that you can, and that’s tied into automation. So, it’s a big portion to continuous deployment, CI/CD pipelines. Once you start the development of those types of workflows that accelerate getting what developers are creating out in front of the customers, whether it’s an internal app or external SaaS or mobile app, accelerating that team velocity is really a key element in terms of making that possible.

    The other area is this notion that you wanna implement systems that reduce the amount of copy and paste. So, that’s what we call the Do Not Repeat Yourself, the DRY approach to infrastructure as code management. So, that’s a key theme behind CloudTruth is, we provide capabilities that let you manage your multiple environments with the faults, inheritances, and overrides from a centralized capability, but still allow flexibility in your environment tree to manage certain sub-environments in different ways as needed.

    So, different developers can have their own custom environment, but they’re gonna inherit default values that are sanctioned by the architecture team or the security team. And then the overrides have to be allowed by a permission basis.

    So, there’s a couple sort of themes that are coming together as we go through 2021 around automation, infrastructure as code, shift left, and the DRY approach to managing input values to all the IAC tools.

    Mike Vizard: Hey, Greg, thanks for being on the show.

    Greg Arnette: Thank you very much. Have a great day.

    Mike Vizard: Alright, awesome. Hey, guys, we learned a lot about security there and things we didn’t know and—hey, there’s hope for the future. Back to you guys in the studio.

    [End of Audio]

  • Natural Language Query (NLQ) is Key for Self-Service BI

    Natural Language Query (NLQ) is Key for Self-Service BI

    Modern business intelligence (BI) and analytics software solutions offer more ways to explore data and find insights than ever before. However, ensuring everyone in the enterprise can use analytics independently, when they need it, remains a challenge.

    For analytics to be adopted across the full enterprise, your tools need to be tailored for all users.

    While many BI solutions today provide streamlined experiences, some data literacy and knowledge is required to fully understand them. Dashboards, for instance, are considered self-service BI tools, but they are often still too technical for the average person to use effectively.

    Today, only two out of five (40%) organizations report their people can analyze data without getting help from IT, according to Ventana Research. To better enable business users to interrogate their data independently, certain BI vendors now provide a natural language query (NLQ) capability that sits alongside their dashboards and reporting. Rather than having to search for answers in a traditional dashboard or chart, NLQ allows analytics users to ask questions of their data directly.

    An Overview of NLQ

    Natural language query is a self-service BI tool that provides the ability for an analytics user to ask a question using non-technical language and get an automatically generated answer instantly. Using data modeling and machine learning technologies to parse questions for key terms, NLQ scans related databases and generates a tailored report or chart that provides relevant insight.

    The integration and implementation of natural language query capability, as well as the complexity of the questions and the types of data supported, varies between vendors. The most common and traditional approach is search-based NLQ, which places a free text search bar somewhere within the user interface (typically on a dashboard) that allows BI users to begin typing a question and get a list of reports and charts generated quickly as potential answers.

    A smaller number of vendors also include support for voice commands in their NLQ solution.

    As NLQ increasingly becomes a part of BI ecosystems, however, some vendors have evolved their natural language offering to account for additional barriers: A user still has to know what question to ask, and how they can use it to avoid inaccurate or irrelevant results to their question.

    The new approach is called guided natural language query, or guided NLQ, which takes the concept of NLQ further by programming the solution itself to guide the user as they type a question, helping them structure it using pre-defined sequences and suggested prompts.

    This eliminates the burden of knowledge or any potential problems in accurately interpreting the semantics (language) of a user’s question, as the system itself assists them in building it, from start to finish. They don’t need prior technical knowledge or need to go to IT to get started finding answers from data.

    When employed correctly, guided NLQ can help make the use of analytics more pervasive and open up analytics for every type of business person in the enterprise—not just experts.

    Self-Service That Suits Every Enterprise User

    The aim of NLQ is to help workers not accustomed to traditional, structured BI tools find insights and information they need to inform and make business decisions, while also being a helpful tool for advanced users throughout the enterprise.

    For non-technical analytics users, NLQ is an easy way to get detailed answers from their data faster than exploring a dashboard or chart and use it as a springboard for their ad-hoc reporting.

    Similarly, advanced users can leverage NLQ, whether guided or traditional, to quickly generate a report or chart and further build upon it.

    Generated insights using NLQ can be added into existing analytic content, such as dashboards, reports and data stories, to enhance them with additional detail, relatively quickly and easily.

    Finally, NLQ can be embedded into the interfaces of your users’ workplace applications, to make analytics far more ubiquitous in their day-to-day workflows. They can ask a question, get an answer, and start exploring data much faster and more easily than via dashboards alone.

    Ultimately, having an awareness of your users’ varying self-service BI needs, and how the new wave of tools such as Guided NLQ can help to further open up analytics to more people, will help you ensure your analytics tools are adopted and usable by everyone throughout the enterprise.