devopsy.kinsta.cloud

Category: IT as Code

  • Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    Survey Shows Increased Focus on Modernizing IT, Retiring Apps

    A survey of 140 enterprise architects and IT leaders published today suggested that, while moving applications to the cloud remains a priority, more attention is being paid to reducing technical debt by retiring applications.

    Conducted by LeanIX, a provider of a platform for managing enterprise architecture and managing value stream management (VSM), the survey found 40% of respondents identified reducing technical debt created by legacy applications and modernizing legacy systems as their top IT priorities. A full 96% said their company has at least one project planned for this year aimed at reducing technical debt with more than half (52%) noting that retiring IT applications is the primary means they will employ to reduce technical debt.

    Nearly 60% considered migrating applications to the cloud to be a high priority, as well. However, less than a quarter of respondents (24%) identified cloud initiatives as a top IT priority. The second most important cloud initiative, identified by 41% of respondents, is to increase the number of SaaS applications being employed.

    Regardless of the approach to the cloud, nearly three-quarters (73%) of respondents said enterprise architects should form a closer connection with software development teams, with an almost equal percentage agreeing on the importance of tracking the business impact of software development.

    However, only 16% of those surveyed considered the evolution and improvement of their security posture a top priority, even though more than two-thirds considered security initiatives—such as improving risk assessment capabilities and adopting more zero-trust IT offerings—as important or highly important.

    Dominik Rose, vice president of product management for LeanIX, said enterprise architects—or someone within IT who assumes responsibility for enterprise architecture—are trying to minimize disruptions to the business as IT environments continue to expand and evolve. The challenge they encounter is there is usually a divide between software development teams and the rest of the business. The size of that divide will vary by organization; in general, though, digital business transformation initiatives should help bridge the gap—assuming enterprise architects can establish and maintain close connections with software development teams, noted Rose.

    LeanIX is making a case for an enterprise architecture management (EAM) platform that provides visibility into IT environments. The company also makes a VSM offering available on top of that platform that provides visibility into software delivery processes. The number of organizations that have adopted VSM platforms remains relatively small, but as organizations depend more on software to drive digital processes, the need for senior business and IT leaders to have more visibility into software delivery schedules is expected to increase.

    In the meantime, it remains to be seen just how aligned DevOps teams are with the strategic goals of the business. The ability to build and deploy software faster does not automatically equate to gaining a deeper understanding of the needs of the business. In fact, there may come a day when software is built and deployed faster than most organizations can effectively absorb unless they have some equivalent of a VSM platform in place.

  • Overcoming IT Complexity With Full-Stack Observability

    Overcoming IT Complexity With Full-Stack Observability

    Organizations embarking on digital transformation journeys tend to develop complex infrastructures. They update their legacy applications while adding multi-cloud, virtual and cloud-native capabilities. Eventually, IT pros find themselves managing diverse, complex and distributed networks including cloud, system, application and database infrastructures.

    To rein in the resulting complexity, organizations tend to amass monitoring and managing tools. The goal is to simplify systems oversight—but instead, silos tend to develop because teams use a wide variety of tools to manage their networks or infrastructures. 

    This piecemeal approach worsens operational blind spots and delays problem resolution. It also increases security exposures. Soon, overwhelmed IT pros can’t keep pace with app modernization or infrastructure dynamics because they’re awash in complexity.

    Though this scenario is common, it’s not inevitable. IT teams can ease their digital transformation journey by implementing an integrated and cost-effective full-stack, end-to-end monitoring service capable of overcoming complexity and silos. 

    Organizations require full-stack observability.

    How Observability Differs From Traditional Monitoring

    Observability goes beyond traditional monitoring. Traditional monitoring helps IT organizations understand the actual state of their infrastructure and applications. It captures and processes volumes of infrastructure and application telemetry data and notifications and displays which components are up, which ones are down and which ones have changed. 

    Usually, traditional monitoring focuses on a specific network, cloud or infrastructure. It tracks application and infrastructure elements so IT pros can identify anomalies and investigate problems as they arise.

    Monitoring relies on metrics-oriented dashboards built to assess telemetry data against manual or basic statistically relevant thresholds. Monitoring tools are invaluable, but they don’t offer cross-domain correlation, service delivery insight, operational dependencies, or predictability. Modern systems have complex multi-cloud environments and a deluge of telemetry data: This counts as a shortfall.

    Observability does more. It measures the internal states of systems by examining the outputs and looks at applications and systems in their entirety—from the end-user experience to server-side metrics and logs.

    But observability also includes monitoring as a critical element. To gain observability, you must first collect information through monitoring. Observability uses the insights and metrics generated through monitoring to understand what’s causing the issue at hand. 

    Monitoring aggregates and displays the data to determine whether the systems are operating as expected. The analysis of this information is compared with expected outcomes and objectives. This allows IT pros to understand the state of their infrastructure and applications. 

    Silos are thus avoided because complex environments are viewed in their entirety.

    Observability in Action

    Once in place, observability allows IT organizations to continuously improve performance, availability and digital experience across complex, diverse and distributed hybrid and cloud environments.

    With observability, organizations can quickly find and resolve anomalies. However, full-stack observability goes beyond monitoring and expedited problem resolution: It supplies insights, automated analytics and actionable intelligence through cross-domain data correlation, machine learning (ML) and artificial intelligence for IT operations (AIOps). It works across massive real-time and historical metrics, logs and trace data.

    Observability goes beyond the silos and the piecemeal approach associated with traditional monitoring. And when observability isn’t limited—when it includes ML and AIOps—it uses the large volume of gathered data and supplies insights, automated analytics and actionable intelligence to help IT staff expedite problem resolution. It also enables ITOps, DevOps and security organizations to achieve consistent, optimized and predictable business service delivery with continuously improved digital experience and IT productivity. 

    The result is customers and employees benefit from better-run systems. The technology provides organizations of all sizes and industries with comprehensive, integrated, and cost-effective functionality through cloud-connected on-premises or software as a service (SaaS) deployment flexibility.

    When embarking on digital transformation journeys, organizations don’t need further complexity—certainly not while they update legacy applications and add a plethora of modern services and capabilities to their stack. The key to reducing complexity is observability.

    Observability simplifies the transformation process. It reduces operational noise to benefit ITOps, DevOps and security teams. They can become more proactive in issue and anomaly detection to achieve optimum IT performance, compliance, and resilience. With full-stack observability, any organization—no matter its size or industry—can reduce IT complexity while readying itself for digital transformation.

  • IBM z16 Delivers AI and Quantum-Safe Levels of Security

    IBM z16 Delivers AI and Quantum-Safe Levels of Security

    Business transformation and disruption is all about data. But it’s not just about collecting huge amounts of data, it’s what you do with that data and how it can enable you to create powerful insights.

    While many people focus on the cloud unicorns, the reality is that industry incumbents have a huge advantage. These businesses have decades of experience which translates into massive amounts of data and business logic. Where do many of these businesses host their most important workloads and data? IBM zSystems—the system that is best known as “the mainframe.” 

    Today, IBM is announcing its latest IBM zSystem—IBM z16. Two weeks ago, IBM spent time briefing the industry analyst community on the business strategy and technical underpinnings of the IBM z16. We met with a variety of IBM business leaders including executives from the IBM Systems division, Distinguished Engineers and IBM cloud leaders. The most significant updates to the platform are the inclusion of a dedicated on-chip AI accelerator and the addition of quantum-safe cryptography.

    It’s important to understand the size of the IBM zSystems ecosystem. The platform is used by 45 of the 50 largest banks in the world, four of the top five airlines and eight of the top 10 insurers, among others. Likewise, the partner ecosystem is huge, ranging from the largest system integrators to small DevOps- and AI-focused technology vendors. Suffice it to say, some of the world’s largest businesses and governments run on IBM zSystems.

    In this article, I will briefly cover the five biggest takeaways from the pre-announcement industry analyst briefings.

    IBM is Bringing AI to the Mainframe

    Many cloud data warehouse and analytics vendors say “Bring me the data.” IBM is flipping the script, because IBM zSystems already houses clients’ most critical customer and operational data. IBM z16 will be shipped with an on-chip integrated accelerator for AI.

    Everyone knows that AI creates a competitive advantage, so why should you care about the on-chip AI accelerator? The last mile of deploying machine learning/artificial intelligence (ML/AI) models is still a huge challenge. Businesses are investing large amounts of money and skills in developing models; however, latency often kills. The difficulty is that ML/AI models need to be built into applications so that the model can be executed at the point of transaction with virtually no delay. This also must be done at a massive scale! Think about the latency and security concerns if near-real-time banking transactions needed to go from a back-end system to a cloud AI platform to check for fraudulent transactions.

    For those of you who have been following the IBM zSystems platform, IBM’s z14 unveiled a pervasive encryption capability. This encrypt-by-default approach without traditional encryption overhead was enabled through an encryption-dedicated chip. Similarly, AI workloads will be performed by the integrated AI accelerator.

    Your AI Infrastructure is Only as Powerful as Your Software Ecosystem

    Developers and data scientists want to use data, ML and AI tools that they know and trust. AI success requires an open stack of software options, not a walled garden. While IBM has a wide range of AI technologies, including Watson Machine Learning for z/os, IBM Cloud Pak for Data and IBM Cloud Pak for Watson AIOps, just to name a few, an IBM-only approach would be a non-starter for many data scientists.

    The IBM z16 AI accelerator supports a wide selection of ML libraries and compilers. Clients can build and train models in a variety of popular frameworks including TensorFlow, SAS, Microsoft CognitiveToolkit (Microsoft CNTK), PyTorch and Keras, along with others.

    The system uses ONNX, an open source tool to enable interoperability of ML/AI models to prepare and deploy the model on the dedicated AI accelerator.

    What does this mean? You can bring your existing data models to IBM z16. In addition, your teams can use their existing preferred vendors while also working with IBM zSystem’s integrated accelerator chip.

    Cybersecurity Arms Race: Quantum-Safe Cryptography is a Growing Need

    Cybercrime is a multibillion-dollar business. Although fairly routine exploits like phishing remain the number-one money generator for cybercriminals, these gangs and nation-state-sponsored organizations are getting more sophisticated. For example, cybercriminals are investing in AI and ML just like traditional businesses. In some cases, cybercrime syndicate engineering employees believe they’re working for a legitimate company.

    What is quantum-safe cryptography? The research is focused on identifying algorithms that are resistant to attacks by both classical and quantum computers. 

    Why is this a growing area of concern? IBM, along with Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) all offer quantum computing-as-a-service. While quantum computing has massive potential for applications across a wide range of industries including drug discovery, chemical engineering and combating climate change, keep in mind that cybercriminals are looking at this technology to unlock complex cryptography algorithms. 

    IBM claims that IBM z16 is a “quantum-safe system.” The company uses a variety of different hardware, software and business process approaches to assure data security. For example, the system includes a new crypto express card with quantum-safe APIs to upgrade existing application security. At a firmware level, IBM z16 has a built-in dual signature scheme.

    In addition, for a number of years, the IBM zSystems platform has taken a zero-trust approach to security which includes a bring-your-own-key (BYOK) framework. IBM can never access the keys to your encrypted data–and neither can cybercriminals and/or governmental organizations—instead, those encryption keys remain inside your firewall.

    IBM zSystems Tech Goes to the Cloud; Mainframe Remains On-Premises

    What a difference a nine can make! Five nines mean 99.999% availability while four nines (99.99% availability) result in more than 47 minutes of downtime per year.

    When I work with C-level executives that have a mainframe within their environment, the role of IBM zSystems is always discussed. In many cases, businesses have explored the possibility of transitioning off of the mainframe, but resilience, predictability and security are the reasons why businesses remain on the platform.

    IBM mainframe services are increasingly being offered in the cloud. Most recently, IBM announced IBM Z testing in the cloud. Likewise, IBM’s Cloud Hyper Protect Crypto Services, a key management approach using a specific security chip module, is enabled by IBM zSystems technology.

    However, you shouldn’t expect mainframe-as-a-service. Between latency, security, resilience, governance and compliance, it’s going to be a long time until you migrate and/or send your mainframe workloads to the cloud.

    As the author of Hybrid Cloud for Dummies and Cloud for Dummies 2nd Ed. (among other books and articles) I can confidently say that the cloud is not a panacea. The business case for moving many mainframe workloads to the cloud doesn’t exist. 

    Digital Transformation Means More Than Slick Apps–Plumbing Matters!

    Don’t get me wrong, mobile check deposits, airline ticketing and contactless hotel check-ins are great, but in many cases, they rely on older systems that have not been updated. 

    A few weeks ago while traveling for work, my flights were delayed for hours. I saw that another flight was leaving within the hour. I was already at the airport and figured I could rebook it via the airline’s app. Of course, it wasn’t that easy—I finally went to the ticketing desk and told the agent that I’d like to book a different flight. The agent then went to work; they spent a long time entering information into their system, talking to a colleague, asking for help and asking me several questions. After about ten minutes my flight was finally rebooked.

    This airline has a great app experience when things are running smoothly (so great, in fact, that I prefer to book my travel on the app rather than the computer). However, even a slight disruption caused everything to go off the rails. It’s clear to me that the company still relies on old, broken processes and outdated technology.

    My Perspective

    Moving AI closer to the data just makes sense. The last mile of AI—moving models into transactions—continues to be a huge challenge. I work with many businesses that have tons of data and do an excellent job retrospectively analyzing that data. However, real-time data-driven decision-making remains a challenge because of latency and the fact that moving data between on-premises and cloud systems raises security and governance risks (in addition to costs).

    Quantum-safe security is a growing concern for highly regulated organizations in the banking, insurance and governmental segments. Over the last several years, financial industry CIOs and CISOs/CSOs at large financial services organizations were focused on establishing a zero-trust approach to security. However, as attacks become more sophisticated, security teams are starting to perform risk assessments on their approach to cryptography. The inclusion of quantum-safe cryptography is important for IBM zSystems customers.

  • Understanding SaaS Security for DevOps

    Understanding SaaS Security for DevOps

    As Software-as-a-service (SaaS) and DevOps adoption grew, new teams were formed to address emerging security challenges. Traditional solutions weren’t built to detect the new vulnerabilities in the cloud and created excessive noise for an already stressed pool of resources.  

    The combination of emerging zero-day vulnerabilities and an avalanche of false-positives ends up increasing security problems and slowing down DevOps projects. The good news is that recent developments in security and visibility are now increasing speed and improving visibility. 

    Gartner forecasted spending on public cloud services would reach $396 billion in 2021 and increase by 22% to reach $482 billion in 2022. SaaS applications based in the cloud have exploded with the market growing 18% each year; 99% of organizations will be using one or more SaaS applications by the end of this year. 

    What does this mean for security, especially for the security of personally identifiable information (PII) and business data in the enterprise? SaaS data includes, but is not limited to, customers’ sensitive PII and payment information; increasingly SaaS applications also house mission-critical enterprise information including product plans, patent information, business and operational processes and human resource records. 

    The extensive data held in SaaS applications presents huge security risks and costs for organizations globally. The average cost of a data breach exceeded $4.2 million, the most in the 17-year history of the IBM Cost of a Data Breach report, and nearly half of the breaches involved compromised PII, the costliest record type to lose, at $180 stolen record—an increase from $146 per record in 2020.

    SaaS Offers New Ways to Do Business but Introduces Significant Risk

    Salesforce is one of the most recognizable and widely used examples of enterprise SaaS software. Recently, analyst Vernon Keenan explained how Salesforce DevOps required guardrails. “Some companies go too fast when it comes to SaaS, DevOps and security, but smart developers and implementers will respect some basic guidelines to keep their product safe.”

    The same is true of other SaaS software platforms and solutions.

    General purpose application security testing solutions aren’t built for SaaS software environments, and often slow down DevOps processes as well as lack the necessary visibility into SaaS environments. Instead, the patchwork of tools must be replaced with a continuous integration and continuous deployment (CI/CD) approach. Specific steps include:

    1. Check all local and remote libraries. Only checking configurations and access controls, which focus mostly on insider threats, misses application vulnerabilities from custom development or app downloads that could open up your SaaS services to external threat actors.
    2. Carefully and routinely check third-party software libraries. If you are only testing source code and ignoring third-party software libraries, you are only securing half of your software application attack surface. CVEs are publicly reported every day on commonly used open source software libraries, showing attackers a direct path to compromise those key components. Running a software composition analysis (SCA) regularly to check all your locally bundled and remotely referenced libraries is a key step in achieving a secure software supply chain.
    3. Don’t assume you’re protected from common vulnerabilities. Static application security testing (SAST) can often miss cross-site scripting (XSS) or SOQL/SOSL injection attacks on SaaS platforms. 

    By identifying security vulnerabilities faster and more accurately, new SaaS security tools can allow organizations to gain the promised benefits of DevOps with better visibility.

     

     

  • Positioning ML Devs and Teams for Success

    Positioning ML Devs and Teams for Success

    Intelligent applications are (by their very nature) complex. While conventional software basically consists of one thing (code), intelligent software involves code, models and data. As previously discussed, three distinct fields—DevOps, MLOps and DataOps—have evolved to govern each of these interconnected disciplines. 

    Moving through the ML life cycle quickly and efficiently requires collaboration between teams in each of the above disciplines. Organizations should strive to make this collaboration as frictionless as possible to position their ML efforts for success. What follows are four places where we believe organizations should focus: 

    • Infrastructure
    • Team structure
    • Tools 
    • Project ownership and KPIs

    Build Dedicated Infrastructure for Each Pillar

    Infrastructure software is not one-size-fits-all across the three pillars of code, model and data. For example, DevOps teams have historically played the infrastructure role in software development, supporting application or product services. Think of regular software engineering teams who are supported by DevOps, producing different kinds of application services. App infrastructure is so baked-in to software development that most of us take it for granted.

    Just as regular software services require DevOps, data and model services require corresponding infrastructure. Data infrastructure is typically concerned with managing tools (such as Airflow installations, Spark clusters and feature stores), building data pipelines and ensuring that data services remain smooth and operational for data consumers. 

    On the other hand, model services are chiefly concerned with creating, running and organizing models in such a way that others can use them efficiently. Since the AI/ML life cycle is incredibly complex, a host of factors need to be considered (e.g., hardware, parallelization libraries, model packaging formats, etc.) to help data scientists and engineers do their jobs efficiently. Robust ML infrastructure along with a dedicated ML infrastructure team goes a long way in helping organizations scale their AI.

    Optimize Team Structure

    Best practices for ML and AI are continuously evolving, and organizations have tried a host of team structures over the years. We have noticed two popular structures for intelligent application development teams emerged in recent years:

    • Pods

    Pod structures involve smaller teams—usually a data scientist, a data engineer and an application software engineer—working together closely to deliver an intelligent feature or product. Due to their tight-knit nature, these teams are positioned to iterate extremely quickly, which often leads to better products and features. However, the closely-knit nature of pods also comes with a downside, as knowledge sharing between pods with different objectives can be difficult.

     

    • Center of Excellence

    In a center of excellence (or COE) structure, all data scientists or data engineers are “pooled” and then assigned to different products or features depending on project requirements and circumstances. In contrast to pods, COE structures tend to share knowledge very easily. However, this arrangement can lead to slower iteration cycles because team members are not dedicated to particular products or features. 

    In our opinion, both pod and COE arrangements can be effective depending on the realities of an organization. Choosing an optimal team structure depends on how the rest of the organization is structured and how reporting relationships are set up. 

    Select Appropriate Tools

    To select the best possible tools for your organization, choose those that foster collaboration and uphold safety across code, model and data teams. 

    The right tools help teams work quickly and efficiently. Teams should be able to discover pertinent information for themselves without having to pull others off of whatever they are working on. For example, a data science team should be able to discover what data access or learn what features exist. Similarly, application teams should be able to discover what models exist, what versions are the latest or how and when to use models. The more that you can make your code, model and data self-serve, the faster teams will be able to build products that are ready to be put into production. 

    Furthermore, proper tools make debugging faster and easier. If you’ve been around ML-enabled features or products for any length of time, you’ve probably been bitten by undeclared dependencies and apps breaking due to upstream changes. In an intelligent app, finding the root of a problem can be extremely difficult because the root cause can exist in any of the three pillars or any combination of the three. Robust tools provide logs and information to help discover what went wrong more easily.

    Finally, governance should play a key role in tool selection, as safety should be a chief concern for ML teams. For example, consider a model that predicts the demographics of a user based on their app usage. While these predictions might be considered acceptable in certain applications, if a model is being used to make financial recommendations or approve credit applications, use of certain demographics may violate various consumer protection laws. Since a software engineer using this model might not be aware of the nuances related to its use, baking in safety checks on model and data use becomes vitally important. 

    Establish Ownership and Determine Appropriate KPIs

    Whether we are working at a company or in an academic lab, our goal always remains the same: build the best product. 

    But “best product” can mean a lot of different things depending on the use case. For example, sometimes teams may be willing to trade a bit of accuracy if a model fails in predictable ways (e.g., in health care applications.) By contrast, an e-commerce recommendation system can optimize for overall model accuracy even if a model isn’t quite as stable. As a result, choosing the appropriate KPIs for model optimization requires careful attention.  

    Similarly, choosing appropriate metrics that make sense for the product and business usually requires a high-level view of a number of factors — user expectations, revenues, user complaints, etc. In our experience, product owners are usually in the best position to make these decisions. KPIs for each of the pillars supporting the intelligent app should be based on key metrics determined by product owners. While these can range, we’ve seen the following KPIs work well:

    • Code — Number of releases, number of bug fixes, number of features that have shipped, mean time to resolution
    • Model — number of model iterations shipped, model quality in production, model performance SLAs 
    • Data — frequency of data refreshes (e.g., every day or every month?), number of data quality issues, speed of access to data

    The key point here is to drive all of these based on the product KPIs and to focus on the agile principle, which is how quickly are you moving and how many deploys are happening. 

    Know what metrics your team is looking to optimize so that you can invest your resources in the right spot. 

  • Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    Lapsus$ Shames Okta/Sitel | Bitcoin Nukes Climate | EU DMA E2EE FAIL

    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: Okta and Sitel under fire over Lapsus$ hack, Greenpeace and others call for bitcoin change, and Europe still hates encryption. (more…)

  • Everything You Need to Know About Cookiecutter

    Everything You Need to Know About Cookiecutter

    Cookiecutter is a templating library for creating project boilerplates in any programming language. When individuals, teams and organizations create projects, they must follow consistent standards so that those projects are easily readable and searchable. Templates accelerate the code writing process, too, since developers are able to spend less time on setup and can get straight to the actual implementation. 

    Cookiecutter is a Python package, easily installable with pip or other package managers. It enables you to create and use templates for microservices and other software projects. It is a command line tool that doesn’t require knowledge of Python to use. Cookiecutter is widely used among software engineers, researchers, data scientists and other technical roles.

    Creating a template is simple and requires updating a cookiecutter.json file. Using a template requires running the cookiecutter command with the appropriate directory to create a new project.

    Here’s an example template for a Python package that the Cookiecutter team maintains. To use the template, install Cookiecutter first and then run the following command in your terminal:

    Cookiecutter https://github.com/audreyfeldroy/cookiecutter-pypackage.git 

    Go through the series of prompts and voila! In just a few moments, you have the skeleton of a completely functional Python package. Swap out the template for something else and you could just as easily spin up a mobile app, a data science notebook, or any other project on your favorite cloud service. There’s an entire community with thousands of templates to choose from.

    Creating custom templates to fit your and your organization’s needs is also simple and powerful. We’ll cover how to do that below.

    Who is Cookiecutter For?

    Cookiecutter is for individuals, teams and companies to standardize their project development process and accelerate new project creation.

    Example use cases include:

    • Learning a new framework: Cookiecutter lowers the barriers to entry for developers unfamiliar with a particular framework. You can find an expert’s template for a framework you’re learning and quickly get started with a configuration that is known to work.
    • Onboarding: Standardization makes collaboration much more manageable. New team members can immediately follow best practices without the risks of copying, pasting and trying to edit just the correct variables.
    • Enforcing standards in an organization: Consistent foldering, file-naming conventions and other patterns enable large teams to maintain an organized codebase.

    Cookiecutter Features

    Templates

    The heart of a template is the cookiecutter.json file, which might look something like this:

    {

      “full_name”: “Alice Cookie”,

      “email”: “foobar@example.com”,

      “project_name”: “Django Boilerplate”,

      “version”: “0.1.0”

    }

    These key-value pairs determine the prompts a developer needs to answer when using a template. The command line interface iterates over the keys, prompting a developer to set the various parameters. If a developer does not specify something, Cookiecutter uses default values.

    A template needs to have files and directories worth copying and reusing, such as the skeleton code for a particular framework. Cookiecutter uses these inputs to modify the template. To connect this boilerplate to the inputs, Cookiecutter uses the Jinja2 templating language. With Jinja2, Cookiecutter identifies all instances of the text {{cookiecutter.variable_name}} and replaces that boilerplate with the actual value of the variable. This works both within files as well as for file and directory names.

    Loops and Conditional Logic

    Jinja2 is very powerful and can do much more than just text substitution. It comes with control structures including for loops and if statements. It even has macros that are analogous to functions in programming languages. Since all of Cookiecutter’s templating uses Jinja2, it can leverage the same control flow features. This opens up enormous possibilities. For example, you could prompt a developer to specify which device types for which they are building an app and have unique behaviors depending on the response.

    Hooks

    Pre/post-generate hooks let you run Python or shell scripts before and/or after generating a project. Inputs from the template prompts are fair game within hooks and work similarly to the way they would elsewhere in the project with Jinja2 syntax. This means you can run a script to validate a developer’s responses to the prompts. Other applications of hooks include cleaning up unwanted files or otherwise using logic that would be complicated by just using Jinja2.

    What Are the Limitations?

    By design, templates are prescriptive with regard to a project’s setup, presenting all kinds of advantages as discussed above. On the other hand, a template might be opinionated in a way that does not align with either an individual developer’s or an organization’s preferences. In that case, it may be worth choosing another template or revising an existing one. Forcing a template in a situation that doesn’t make sense is less-than-ideal.

    What Are Some Alternatives or Extensions?

    Boilerplate for Specific Frameworks

    While Cookiecutter is compatible with almost any framework, some frameworks do have custom boilerplate that is readily available. If you were to start a React app, for example, there is a great boilerplate available to use as a starting point, and other communities often maintain similar ways to get started. Boilerplate is not incompatible with Cookiecutter, and you’ll find templates from popular boilerplate that you can use, too.

    Cruft Keeps Templates Organized

    As with any new process, there is some overhead involved to stay organized with Cookiecutter. When a team starts to manage dozens of templates or more, it’s especially important to keep templates up-to-date. Cruft works alongside Cookiecutter to not only make projects but to update existing ones as a template evolves. Cruft also has template validation capabilities to ensure projects match the latest version of a template.

    Learn More About Cookiecutter

    The Cookiecutter community has lots of resources to help you dig deeper.

  • How Observability Can Improve Gaming

    How Observability Can Improve Gaming

    Competing in the gaming industry is becoming increasingly costly. To attract new players, millions of dollars are spent in user acquisition (UA), development and cloud infrastructure. As the space becomes more expensive, revenue and cost optimizations can become a matter of survival. 

    The cost to businesses because of server outages, game response lag or generally poor performance can equate to billions of market cap of gaming companies. The value of observability in modern games is about ensuring that revenue opportunity is not missed in a costly operating landscape. Observability assures that all investment spent on user acquisition is protected and that gaming user experience (UX) is maximized. And user experience depends not only on how the game’s UI is performing but also on the entire gaming environment performance and reliability.

    A modern gaming environment is usually highly distributed—a lot of pieces have to come together. The engineering team develops code for the gaming application, which can consist of many microservices, containers, managed cloud services, third-party APIs and serverless functions. Game designers create game levels, the art team produces visual effects and animations and the audio department creates game audio. Once these moving parts are packaged together, the game service has to be deployed on cloud infrastructure and the game itself shipped as executables for consoles, mobile devices and laptops.

    gaming observability

    All these elements generate massive amounts of observability data, particularly if a game is popular and played by millions of users. Thus, making sure that all gaming elements are working as expected means that gaming companies have to implement efficient ways of collecting and analyzing the massive amounts of that data. That data comes from gaming services, consoles and other sources in real-time. For instance, it is not uncommon to deal with hundreds of terabytes of ingested log data per day. As a result, improving the gaming experience can be quite challenging for gaming companies with large-scale operations. The companies’ success depends on how efficiently they can harness all the data generated by gaming environments.

    This is where observability comes in. Observability provides critical insights into what is—or what may be—wrong with the game, all its moving parts and user experience. Powerful observability capabilities are essential, including processing vast amounts of data (logs, metrics, traces, etc.) in real-time, managing fluctuating observability data from variable user loads and running concurrent real-time queries on a massive scale.

    So, what, exactly, needs to be measured for a great gaming user experience?

    Measuring the Gaming User Experience

    Gaming companies are under continuous financial pressure to deliver new features that attract and retain new users in order to offset mounting operating expenses. Attracting new users is a balancing act from the gaming companies’ perspective. If they move too slowly, they will lose gamers. If they move too quickly, the gaming user experience can deteriorate due to newly introduced bugs. Gamers can be very vocal on social networks, especially if their intent is to express their dissatisfaction with compromised gaming quality. As a result, companies are forced to balance the rate of feature introduction with user satisfaction. That’s why they need to measure user experience continuously.

    To improve gaming user experience, gaming organizations must establish measurable key performance indicators (KPIs), which can drive improvements and overall quality. KPIs include, but are not limited to: 

    • User video quality (frames per second)
    • Memory usage
    • Crash reports count
    • Database performance measurements
    • Service latencies 
    • User request count
    • Game-specific errors and warnings count
    • Code quality measurements, such as automated test coverage success criteria (a part of the CI/CD pipeline)

    Monitoring Service Latency for a High-Quality Gaming Experience

    Gaming applications are often bursty when it comes to user load, especially during the introduction of new games or new features. One of the critical indicators to monitor is service latency to manage fluctuating user demand during those times. 

    DevOps teams and SREs need to collect logs at a massive scale to analyze the performance of services, infrastructure and individual host utilization metrics such as high CPU utilization. This information gives engineers clues about the sources of bottlenecks and potential deterioration related to service latency. And logging tools need to be able to deal with this fluctuating demand, too. This level of insight into the state of the gaming application helps engineers troubleshoot issues before gamers face increased service latency that can impact their gaming experience.

    Analyzing Game-Specific Observability Data

    Game developers can create custom logs and metrics and combine those with observability data from the gaming engines. Both must be analyzed to assure a high-quality user experience. Some of the common gaming data parameters available for analysis are:

    • Log data that indicates when a player joins and leaves the game (associated with the player’s name)
    • The location of a player reported at specified times
    • Logs related to significant gaming events associated with each player (such as goals achieved or actions performed)
    • Logs related to chat messages between players, player location, the time when the message was generated and message context

    The more data collected, the better the chances to understand any issues that can turn players away from the game. Observability data management should evolve in parallel with game development. As new features are added, the code should be instrumented with KPIs to ensure the quality of the newly introduced code in the long run.

    Database Performance Monitoring is Critical for Gaming User Experience

    To store time-sensitive gaming data, DevOps teams must use fast databases. The database performance and how fast the game’s properties are retrieved from a database directly impact user satisfaction. Slow database performance negatively affects the gaming user experience. For DevOps teams to avoid any service issues, it is a must to measure key database performance indicators such as response times metrics, out-of-memory error logs and others.

    Fast databases could be expensive in the extremely competitive market where gaming companies are always looking for cost optimization to survive in the business. It’s non-trivial for DevOps teams to monitor user experience related to database performance and, at the same time, to look for ways to optimize the cost of fast databases.

    Build a Pipeline and Delivery Monitoring

    For a large-scale video game, new code is often pushed many times per day. Builds can be significant and deployed across many gaming consoles and end devices. Continuous build pipeline and delivery monitoring are crucial for frequent and commonly large software deployments.

    With large builds deployed daily over the network to thousands of gaming platforms—where each platform receives a massive amount of data—monitoring of build deployments should be automated. Errors from log data should trigger alerts and drive redeployments. QA automation is necessary to reduce the burden of QA efforts and make build deliveries less error-prone and less tedious. 

    Better Observability Improves In-Game Commerce

    Insights into user behavior are as important as monitoring possible issues affecting user experience. Observability tools can provide key insights into the overall engagement of all game users. High engagement then drives more excitement. Higher user excitement may increase the success of ad campaigns and accelerate in-game purchases.

    Observability Tools for Managing Gaming Experience

    When thinking about observability tools that can be instrumental in driving continuous improvement of user experience in the gaming industry, the following functionalities are important:

    • Ability to ingest and analyze log data at petabyte-scale and beyond in real-time to avoid gaming experience deterioration.
    • Zero-schema and ability to accept observability data in various formats from various gaming platforms, cloud servers, gaming consoles, and mobile devices. Because gaming environments use different third-party software packages, logs may come in many formats.
    • Ability to create alerts on collected observability data. Alerting can improve user experience by monitoring properties such as the number of active users experiencing client errors. 
    • Capability to handle backpressure when critical issues occur is essential. An alert storm can clog the data pipes, and the observability tool can be in the dark for hours unless it is designed to cope with backpressure.
    • Ability to collect data from build pipelines to monitor frequent and commonly large software builds being deployed daily over the network to numerous gaming platforms.
    • Capability to collect data from cloud environments such as cloud infrastructure monitoring. 

    Observability is key to protecting gaming revenue opportunities and assuring the success of video games, as long as you know what to look for in observability tools that are used to gather data from gaming environments.

  • How DevOps is Revolutionizing Embedded Development

    How DevOps is Revolutionizing Embedded Development

    There’s something curious happening on the desktops of embedded developers around the world. From home offices to cubes to labs, in lamp-lit rooms late at night and sun-lit rooms early in the morning, developers are doing something different. They’re beginning to implement DevOps practices in their embedded development.

    Something quite serendipitous has occurred to make this possible: The parallel rise of cloud-native computing and the explosion of internet of things (IoT) devices and edge technologies. A world with billions of embedded devices connected to the internet all the time, every minute of every day, requires a new way of designing, testing, deploying and maintaining these devices. At the same time, cloud-native computing has introduced continuous delivery (CD) and continuous integration (CI), among other methods, to enable automated software builds that are reproducible. This is creating a revolution in the embedded world.

    Until now, embedded software was written and deployed and then remained static in perpetuity because it was isolated. Not anymore.

    The Slog, Security Demand New Thinking

    Embedded software developers have traditionally faced a monumental slog to build projects. Typically, embedded developers have had to build an entire platform to build new software, including the kernel, the distribution and more. And all of that software would need to get (re)built anew every single time something changed. Everything had to be checked in. Everything had to be rolled out. There was a version control infrastructure team, a CI team, a QA team—and they all had to work together and be aligned to meet the production schedule.

    This approach to developing was incredibly slow, costly and clumsy and in no way architected for today’s world of connected devices, IoT and the edge. Consumer product makers (home appliances, for example) simply don’t have the resources to provide frequent updates. Additionally, consumers are not used to frequent updates on consumer devices that are not their phones or laptops. With the rise of modern applications, it is just no longer acceptable to build static software that is never changed or updated.

    With billions of devices connected to an always-on network, large-scale security vulnerabilities have never been a bigger concern or consideration among companies that have millions of nodes on a network. Today, companies need to be continuously connected to all of their nodes and devices to properly maintain and secure them.

    Enter DevOps and Embedded Innovation

    DevOps has already transformed the way cloud-native applications are developed. Software gets built often, but it also gets deployed often. That’s why web apps are constantly being upgraded. Now, embedded is poised to take advantage of this software version control system that automates software builds and that is reproducible. Bringing DevOps to the embedded software ecosystem is about providing a set of tools or a platform that does the version control, CI and CD all in a single package—a platform to simplify the workflows for companies that typically have to build all of this themselves now can deliver opportunities for tremendous efficiencies and innovation.

    Consider the airline industry as it was 60+ years ago. At that time, the airlines built their own planes from start to finish. Today, Boeing and Airbus build all airlines’ planes. Of course, each airline can customize their fleet from the overall flying experience to the interior branding, but everybody is leveraging the same core technology because airframes are really hard to build and the differentiation happens on top of that foundation.

    Similarly, embedded software developers can focus on the customization of their product, not the time-consuming build that provides no differentiation. This is the concept behind the cultural shift we see in embedded software: Buy the airframe and customize it rather than build it yourself. Also inherent in the DevOps model is a distributed development practice, where different team members in different roles can be anywhere in the world and still work together seamlessly.

    The pandemic certainly created more demand for this model, but distributed teams aren’t going away and are more prevalent than ever in technology development. Many embedded software developers are still working in the same way they were in the 1980s and 1990s. With DevOps practices and platforms in place today, embedded software developers can focus on the value-add of their application. By taking all the complexity out of building it yourself, companies today can simply leverage easily consumable and reusable tools to achieve what cloud developers have been doing for years.

  • Securing APIs at the Speed of DevOps

    Securing APIs at the Speed of DevOps

    In the 2021 State of DevOps Report, 83% of IT decision-makers told Puppet that their organizations were in the process of implementing DevOps practices to improve the quality of their software, the speed of their delivery and the security of their systems. Those DevOps organizations varied in their stages of evolution, however. For example, respondents in the middle stages of their journey reported that culture blockers such as unclear responsibilities and insufficient feedback loops were making it difficult for them to continue their DevOps journeys and join the ranks of high-evolution organizations. Such obstacles help to explain why 97% of high-evolution organizations had already applied automation to their competitive tasks compared to just two-thirds of mid-level and a quarter of low-evolution teams.

    The Importance of APIs to DevOps

    The prevalence of automation ties into the importance of application programming interfaces (APIs) for any organization’s DevOps journey. In the words of IBM, an API “enables companies to open up their applications’ data and functionality to external third-party developers, business partners and internal departments with their companies.” APIs, therefore, enable the services and products of different companies to communicate with one another in a way that streamlines and/or augments functionality for the user.

    That said, users aren’t the only ones who benefit from APIs. DevOps teams do, too. Many of these team members deal with increasingly automated processes as part of their daily tasks, so they need APIs that can help them to deploy and configure their infrastructure. APIs can also help DevOps teams gain detailed information about an app during runtime. DevOps staff can use these insights to proactively address issues before they lead to disruption.

    Security Obstacles of APIs and DevOps

    Despite their benefits, APIs and DevOps aren’t without their security challenges. Contemporary Computer Services, Inc. (CCSI) identified several security hurdles that organizations may encounter along their DevOps journeys. These include the following:

    A fast development process: DevOps introduces a faster speed of software delivery. In their efforts to keep up with this demand, developers might make coding mistakes that leave applications vulnerable to attack. Absent a timely security review, those vulnerable products and services might make it into production, granting attackers an opportunity to exploit the flaws and to try to access affected customers’ digital assets.

    Poor collaboration: No DevOps journey will succeed without collaboration between development and operations. When there’s a lack of joint processes, these teams may stick to their silos. This way of working may leave security gaps if development and operations aren’t communicating about the management of their credentials, tokens, SSH keys and other secrets, for example.

    Those security challenges can then spill over into APIs. The speed of development along with poor team communications may give rise to multiple versions of the same API. This redundancy contributes to a sense of what’s known as API sprawl, a phenomenon where the number and reach of organizations’ APIs grow exponentially. API sprawl comes with its own obstacles including maintenance difficulties and broken clients, issues that provide attackers with more opportunities for infiltrating the organization’s systems. This reality helps to explain why 91% of enterprises experienced an API security incident in 2020 and why malicious API traffic increased by 300% in the middle of 2021.

    How Can Organizations Address These Security Challenges?

    For an answer to this question, we look back to what highly evolved DevOps organizations are doing. Most organizations are focusing on DevSecOps. In Puppet’s report, 51% of respondents said that they are integrating security into their DevOps requirements, with even more saying the same about design (61%) and build (53%). An additional 52% of survey participants indicated that they’re bringing security into their testing. By contrast, mid- and low-evolution organizations mainly engaged in security when they were in the process of preparing for an audit of their production systems or when they learned of an issue affecting production.

    Beyond those areas of focus, organizations need to emphasize runtime protection. Salt Security agrees with this statement, noting how organizations need to “security test your APIs, but know that you will also need runtime protection to catch changes that don’t go through standard build process and abuses that testing tools aren’t designed to find.”

    Finally, organizations need to treat DevSecOps as the cultural change that it is. They can do this by assigning security responsibility to one person from their DevOps team. Doing so will help to ensure that teams won’t overlook security during their jobs. Simultaneously, organizations can conduct security awareness training for their developers and regularly invite both development and operations to share their stories, priorities and successes with one another. This will help to foster collaboration, thereby minimizing instances of API redundancies and API sprawl across their systems.