staging-devopsy.kinsta.cloud

Tag: devops

  • How Event-Driven Architectures Drive Real-Time Operations

    How Event-Driven Architectures Drive Real-Time Operations

    People, events, the human brain—in fact, the whole world operate in real-time, but businesses have struggled to keep up. With the help of event-driven architecture (EDA) and the Open API economy, businesses can now do the same. The power of an event-driven world means that, after years of geopolitical events affecting how businesses operate, many businesses are starting to uncover real value by truly being able to operate in real-time.

    Whether it be retail and manufacturing or energy and resources and financial services, locating and responding to vital issues within a company’s supply chains or product lines in real-time, is key to success.

    Amazon’s CTO, Dr. Werner Vogels, said that “the world is event driven” in his keynote speech at AWS re:Invent in December 2022. Now, new IDC research unveils that nine out of 10 of the world’s largest companies will deploy real-time intelligence driven by event-streaming technologies by 2025.

    But What’s the Secret Behind Such Success?

    A recent IDC Infobrief, sponsored by Solace, surveyed over 300 enterprise IT professionals in North America, Asia and Europe, all of whom work for large companies implementing or considering EDA. The results are quite telling–an overwhelming 93% of respondents at companies that have deployed EDA across multiple use cases said EDA has either met or exceeded their expectations. In addition to technical advantages from EDA, most businesses also see clear business benefits: A full 23% of respondents reported increasing productivity; 22% said better customer acquisition and 18% saw revenues increase as a result of EDA efforts.

    1. Get Support From the Top to Ensure Alignment Throughout

    Expanding the footprint of EDA across the enterprise is a journey, and every journey starts by assembling those that are critical to its overall success. Business sponsorship and engaging key stakeholders is vital, especially in the early days of EDA adoption – 56% of respondents in the early EDA stages cited this as a priority when ROI and business benefits may not be immediately clear.

    The impact of well-aligned C-suite, operational and technical teams is reflective of business-level digital maturity, too. As 35% of respondents at an advanced stage of EDA rollout felt C-level support was critical, it comes as no surprise that respondents with higher levels of EDA maturity also have higher levels of overall digital maturity, including digital strategy and change management support.

    2. Tackle Complexities Head-On With the Backing of IT

    As EDA becomes more pervasive across an organization, demands on IT become more sophisticated, requiring a deepening of EDA skills in the IT organization, notably with DevOps teams, developers and architects. More than one-third (36.1%) of respondents cited the lack of skills to execute EDA as a hurdle to adoption. Approaches to logging, governance and oversight (30.7%) can also become increasingly challenging and must be thought through carefully.

    This is where EDA providers themselves need to step up and provide adequate training and a certification path for architects DevOps and developers looking to gain the fundamental knowledge and skills to design and implement event-driven systems. This should include technical details such as understanding various design patterns for EDA, microservices choreography versus orchestration, the saga pattern and RESTful microservices. Education should also clearly define and demonstrate key concepts and tools for EDA success, such as event portal, topic hierarchy best practices and event mesh.

    3. The Benchmark for Success Chops and Changes: Businesses Need to Go With the Flow

    The right measures of EDA success in the early days of adoption are not the same measures as EDA adoption grows over time.

    Fewer EDA-mature organizations cited “cost reduction” (23%) and “number of projects completed” (31%) as top measures of success. In the medium term, after two or three use cases, most organizations saw “operational stability” along with “number of projects” to measure success. Further, after broad adoption, “increased revenue” (43%), “operational stability” (32%) and “amount of resiliency” (30%) become more important measures.

    This changing set of measures is reflective of the maturity curve of EDA adoption across multiple applications within a business’s ecosystem. A business is truly operating in real-time when deploying EDA across key customer-facing, employee-facing and supplier-facing organizations. This is where revenue is being generated in high volumes, organization-wide – hence stability and resilience become key to ensuring things continue to run smoothly on what can often be a global scale.

    4. Keep Everyone in the Loop

    It is essential to take the company with you along the entire journey. The research showed the bumps in the roadmap. In the early stages of EDA maturity, lack of understanding of EDA benefits and inconsistent buy-in are the most frequently cited organizational challenges (38%). As organizations progress to a centralized EDA status, cost concerns (42%) and finding the right use cases (36%) can hamper success. More advanced stages of EDA also cite a lack of understanding of EDA benefits (45%), and cost concerns (39%) but change resistance (38%) becomes a major hurdle.

    Continuous focus on change management and communicating business benefits is vital. The core group of invested stakeholders who began the journey must band together to demonstrate the value of EDA clearly and consistently to other areas of the business on a regular basis.

    5. Recognize the Benefits That Partners Bring to the Table

    To accelerate business and technical benefits and reduce the impact of challenges, survey respondents cited “finding a supportive partner to assist with the implementation of EDA” (37.7%) as a critical consideration. Partnerships and product integrations with the providers of preferred business software and SaaS services can make it easy to event-enable an organization. Given the amount of new technical skills and learning previously cited, this can provide peace of mind for organizations taking their first steps on the journey to EDA.

    EDA isn’t just a change in IT architecture, it’s a mindset that applies to modern business leadership organization-wide. To keep the momentum during the journey, respondents also noted the use of a robust change management plan that “ensures coordinated middle management support” (35.1%), as they are typically accountable for getting work delivered and reporting across the organization.

    EDA Becomes the Norm

    The InfoBrief results speak for themselves – EDA is quickly becoming the “normal” process for businesses looking to operate in real-time. As more and more companies recognize the business benefits at stake, understanding these five requirements will be a necessity for successful EDA deployment.

  • GraphQL API Visibility Ensures Enterprises Can Escape Lock-In

    GraphQL API Visibility Ensures Enterprises Can Escape Lock-In

    While GraphQL is still early in its enterprise adoption curve, the runtime query language (and replacement for REST APIs) has already built an impressively robust ecosystem for jumpstarting major enterprise-grade deployments. Among the appeals of GraphQL are its open source implementations and breadth of available server types, which combine to offer enterprises flexibility and the benefits of best-fit solutions.

    However, operating GraphQL in production, maintaining GraphQL APIs at enterprise scale and achieving the requisite GraphQL visibility and security require complementary tools and services. This is where enterprises can fall prey to vendor lock-in and lose the flexibility to change and control their own deployments if they aren’t careful.

    Enterprises need vendor partners to manage their GraphQL deployments effectively, and vendors are glad to offer comprehensive SaaS solutions. But enterprises must understand that a vendor can seek to capture their long-term business by coercion—straitjacketing customers by hosting their entire GraphQL infrastructure and GraphQL gateway and making it, well, not exactly easy to let go. They can unleash particularly nefarious practices, using proprietary features to force customers to migrate to certain technologies or purchase expensive upgrades to keep their crucial GraphQL deployments afloat. Enterprises must be wary of allowing this vendor lock-in to happen for their own good.

    Knowledge is essential to maintaining the balance of power in vendor relationships. Enterprises must understand their GraphQL graph and key measures to correctly assess current vendors and maintain agility and control over deployments by not entrusting their entire fate to any one partner.

    These are the specific areas where enterprises should seek out intelligence and reliable metrics in order to choose their own future with GraphQL:

    Understand Your Overall Graph (and Subgraph) Utilization

    Establishing an accurate overview of your graph utilization—and harnessing actionable insights—are crucial, foundational steps that lay the groundwork for deeper analysis and better decision-making. You need to know what graph and subgraph objects and operations your most important API users heavily engage with and which objects and operations are underused or not used at all. You need visibility into who is using GraphQL APIs and how. Getting to actionable intelligence should also tell you where errors are most likely to occur and what’s causing them, as well as where major performance bottlenecks pop up during heavy load events.

    With this overview available, the next steps call for building a depth of knowledge in each of these five areas:

    1) Understand areas of heavy graph and subgraph usage

    Knowing exactly where heavy usage occurs in your graph puts you in a position to upgrade or migrate your GraphQL API server or gateway on your terms while mitigating outage and error risks. Specifically, you want to know which operations in your graph are executed most and how often, which graph objects and fields are consumed most often, and which subgraphs support those most heavily burdened areas in your supergraph. This knowledge and some careful planning help to put successful GraphQL server or gateway changes within your power and also reduce risk when introducing changes to areas of the graph under heavy consumption.

    2) Understand where your graph is underused

    GraphQL migration and modernization efforts are simpler—and carry less risk—when you first remove any unused functionality and reduce your scope as much as possible. To do so, you need visibility into your graph’s least executed operations, objects and fields, and subgraphs, as well as any operations with zero recent usage. Then, flag low-use graph areas you can deprecate, replace or just remove to simplify your deployment before making changes.

    3) Understand your GraphQL API users and usage

    You want a seamless experience for your GraphQL API users throughout any changes you make, especially for the users and graph-usage patterns most crucial to your business. That means knowing the frequent users of the areas of your graph under the most heavy usage. You also want to recognize and bolster any GraphQL operations that your most important users frequently call, in addition to the objects and fields those users consume.

    4) Understand graph errors and potential error hotspots

    The right actionable intelligence will prepare enterprise teams to anticipate and address graph errors. This requires visibility into where, when, why, and how often graph errors occur and error hotspots (for example, high P95 latencies indicative of potential timeouts). Insights into which users feel the brunt of graph errors are also valuable in shaping mitigation strategies.

    5) Understand graph performance bottlenecks

    Bottlenecks caused by your GraphQL server or gateway itself may call for a shift in your graph’s underpinnings. Bottlenecks can also arise from costly queries of substantial depth and height, especially when these queries see intensive use.

    To foresee and address bottlenecks, actionable insights include the average and P95 latencies of your graph’s most-called operations and the heights and depths of your graph queries with the worst performance metrics. You also want to know the number of times that bottlenecked operations get called each day, the subgraphs at the root of bottlenecks, the latency added by supergraph query planning, and which users are impacted the most by bottlenecks.

    Graph Knowledge = The Power to Avoid Vendor Lock-In

    Implementing the GraphQL API visibility and actionable intelligence strategies covered here help ensure that an enterprise has the means to modernize or migrate as necessary to preserve its strategic independence. Those unfortunate organizations already in the grip of vendor lock-in may need to bide their time but should still use these same techniques to improve and decouple their fundamental GraphQL services from their vendor-controlled GraphQL technology. There’s no acceptable reason why organizations relying on free and open source GraphQL servers and gateways should find themselves stuck in proprietary software arrangements. Thankfully, the right knowledge can deliver enterprises a more flexible future as they modernize API development with GraphQL.

  • Avoiding Cloud Lock-In Amidst Potential Regulatory Change

    Avoiding Cloud Lock-In Amidst Potential Regulatory Change

    At the end of my street, there’s a beautiful and much-admired garden with vibrant flowers and a well-manicured lawn. Next to this splendid garden is an abandoned vacant lot, long-neglected and overgrown with weeds. Every time I walk by, I think about how this neglected space could be transformed into something magnificent (like this garden), but no one wants to take responsibility for it. Similarly, many CIOs and CTOs have “discarded vacant lots” to deal with in their own work lives: The problem of cloud lock-in.

    Cloud lock-in can be a significant headache for business leaders. Even the UK’s communications sector regulator, Ofcom, has expressed concerns about the issue. Earlier this year, Ofcom announced that it would refer the UK cloud market for investigation to the Competition and Markets Authority, highlighting barriers to interoperability and concerns about high egress fees charged by the cloud hyperscalers.

    But organizations shouldn’t just wait (and hope) for regulators to solve this problem. As a true believer in harnessing the full benefits of the cloud, I propose two practical ways to combat cloud lock-in.

    The Upside of a Technical Approach

    The first option is straightforward: Have an honest conversation with your cloud service account leader. Express your concerns about lock-in and negotiate more favorable terms and conditions. This approach might yield some results, but it’s not a guaranteed success. So, there’s a more effective strategy: Adopt a technical approach that empowers you to avoid vendor lock-in altogether, without costing you an arm and a leg.

    Imagine that, instead of trying to turn your neglected space into a garden alone, you could access a ready-made gardening community, where multiple people work together to create something amazing. The same principle applies to cloud databases. Rather than relying exclusively on one hyperscaler’s technology stack, you can opt for platforms that offer portability and flexibility across different cloud providers.

    Let’s consider databases, a critical underlying component of many mission-critical business applications. Each cloud hyperscaler will offer a range of SQL, NoSQL, and graph database options, which cater to various types and scales of technical problems. The challenge is to avoid getting locked into a single cloud stack, which hinders your ability to switch between clouds if and when needed.

    One viable solution is to choose “vanilla Postgres” – the basic open source version of PostgreSQL available from postgres.org or any cloud provider. This will certainly provide initial flexibility, but you are likely to encounter limitations as your application grows and requires enterprise-level features.

    The real benefit of the cloud lies in modernizing your data layer to fully exploit cloud-native features like scalability and resilience.

    To achieve this, you need databases that run across different public clouds and share common APIs. Born-in-the-cloud technologies, designed from the ground up for cloud environments, offer the most flexibility and benefits.

    Examining your current cloud vendor’s offerings is natural, as you’re already on their platform. However, keep in mind that these services are customized to their specific cloud environment only, so this could limit your future growth. If you decide to change cloud providers or adopt a multi-cloud strategy, moving across the cloud database “matrix” can be cumbersome due to the inconsistent APIs.

    If you were restricted to a single set of gardening tools when trying to transform that discarded space into a beautiful community garden, it would be nearly impossible and would not be fit for purpose.

    You need to realize that these services and their functionality will always need to be customized in some way to the specific cloud environment. AWS’s fully managed relational database engine, Aurora, is compatible with MySQL and PostgreSQL, but it was specifically designed to run on Amazon. This means it can’t run on-prem, and it certainly won’t work in GCP (Google’s cloud).

    As a consequence, you will have to make time-consuming and costly changes to your application to accommodate a bespoke version of PostgreSQL that will run efficiently in the cloud environment of your hyperscaler partner. You’re going to be locked into that version of the application because it can’t really work anywhere else. The same applies to the Google equivalent of vanilla Postgres (CloudSQL for Postgres), or the Microsoft version (Azure PostgreSQL).

    If you truly want a multi-cloud strategy, you need to consider how you go, for example, from mid-range Google to low-end Amazon. Scaling is much discussed, but surely one of the main selling points of cloud is that you can go down as easily as you go up.

    The Business Advantages of Multi-Cloud are in Reach

    To achieve the advantages of multi-cloud, you need to consider databases that offer common APIs and portability across clouds. There are several open source PostgreSQL-based database options available, which enable you to keep your cloud database options open and avoid the trap of cloud vendor lock-in.

    The wait for regulatory intervention might be long and uncertain. Taking proactive steps now to mitigate cloud lock-in is crucial.

    Adopt a scalable open source PostgreSQL option to immediately enjoy many of the benefits of multi-cloud. Embracing this strategy now can spare you potential panic moves when and if regulatory changes come into play.

    By freeing your business from the shackles of cloud lock-in, you can unleash the true potential of multi-cloud environments. Just like that “discarded vacant lot” waiting to be transformed into a beautiful garden, your applications can blossom in a multi-cloud ecosystem, which allows you to easily scale up or down and enjoy the best that each cloud provider has to offer.

    So, don’t wait for someone else to fix the problem. Take action today and start cultivating your multi-cloud future.

  • What DevOps Teams Need to Know About Responsive Web Design

    What DevOps Teams Need to Know About Responsive Web Design

    The role of DevOps in modern software development extends beyond just coding, testing and deployment. One of the significant areas where DevOps teams can bring value is delivering a positive user experience, a critical competitive advantage in the digital era. Responsive web design (RWD) is a cornerstone of a friendly user experience, allowing for seamless website functionality across various screen sizes and devices. 

    This article explores RWD and its fundamental principles and explains how RWD impacts web application development and deployment. We will review critical considerations for DevOps teams such as performance optimization across devices, the integration of responsive design into CI/CD pipelines, automated testing, the importance of a user-centric approach and consistent monitoring and troubleshooting. The objective is to equip DevOps teams with the necessary knowledge to effectively implement and support RWD, enhancing the user experience and significantly improving overall user satisfaction and engagement.

    What is Responsive Web Design?

    Responsive Web Design is a web development approach that makes your website layout adjust according to the size of the viewer’s screen. This means that your website looks and functions optimally on a wide range of devices, from desktop computers to tablets and smartphones. The primary goal of RWD is to ensure that users have an efficient and enjoyable experience, regardless of the device they are using.

    With the increasing use of mobile devices for internet access, it is essential that your website is accessible and user-friendly on all platforms. By implementing RWD, your organization can ensure that your website offers a seamless user experience, no matter the device.

    RWD removes the need for creating different versions of your website for different devices. Instead, you can have a single website that adjusts automatically to fit any screen size. This not only improves user experience but also saves you time and resources in website development and maintenance.

    Understanding the Principles of Responsive Web Design

    Fluid Grid Layouts

    A fluid grid layout is a key principle of RWD. It involves designing your website layout in relative units, such as percentages, instead of absolute units like pixels. This allows your website layout to resize dynamically to fit the screen on which it is viewed.

    The advantage of fluid grid layouts is that they offer more flexibility than fixed layouts. They allow your website to adjust smoothly to different screen sizes, ensuring that the user experience is not compromised. This is particularly important in today’s digital landscape, where users access websites from a wide range of devices with different screen sizes.

    Flexible Images and Media

    The second principle of RWD is responsive images and media. This means that your images and media files should be able to resize automatically to fit the screen size. This is essential to ensure that your images and media do not distort or overflow when viewed on smaller screens.

    Flexible images and media enhance the visual appeal of your website on different devices. They also improve the loading speed of your website, which is a crucial factor for user experience and search engine ranking.

    Mobile-First Design Philosophy

    Mobile-first design philosophy is another key principle of RWD. As the name suggests, this approach involves designing your website primarily for mobile devices and scaling it up for larger screens.

    The mobile-first design philosophy is based on the reality that a growing number of users are accessing the internet through their mobile devices. By designing your website with a mobile-first approach, you can ensure an optimal user experience on mobile devices.

    Progressive Enhancement

    Progressive enhancement is the fourth principle of RWD. It involves building your website in layers, starting with a basic layer that works on all devices and then adding more features and functionalities for devices with advanced capabilities.

    Progressive enhancement allows you to provide a basic, functional website for all users regardless of their device or browser. At the same time, it enables you to offer an enhanced website experience for users with modern devices and browsers.

    How RWD Affects Application Development and Deployment

    Responsive web design has a significant impact on the development and deployment of web applications. It affects various aspects of the process, including the codebase, development and testing process, user interface design and deployment and updates.

    Unified Codebase

    One of the main benefits of RWD is that it allows you to maintain a unified codebase. Instead of creating separate versions of your application for different devices, you can have a single codebase that works across all platforms.

    A unified codebase simplifies the development and maintenance process. It eliminates the need for duplicate coding and testing, saving you time and resources. It also ensures consistency in your application, as all users are accessing the same codebase, regardless of their device.

    Development and Testing Process

    RWD also influences the development and testing process. Since your application needs to work optimally on various devices and screen sizes, you need to incorporate responsive design considerations into your development and testing process.

    Responsive design testing involves checking your application on different devices and screen sizes to ensure that it functions and displays correctly. This can be done manually, using device emulators or through automated testing tools.

    User Interface Design

    The user interface (UI) design of your application is also affected by RWD. A responsive UI design ensures your application is easy to use and visually appealing on all devices.

    Responsive UI design involves creating a flexible layout that adjusts automatically to the screen size. It also requires you to design intuitive navigation and interaction elements that work well on touchscreens and desktop interfaces.

    Deployment and Updates

    Finally, RWD has implications for the deployment and updates of your application. With a responsive application, you can deploy and update a single version of your application for all devices.

    This simplifies the deployment and update process and ensures that all users have access to the latest version of your application. It also makes it easier to fix bugs and issues, as you only need to update a single codebase.

    Key Considerations for DevOps Teams

    Implementing RWD is not a straightforward task. It requires careful planning and consideration. Here are some key considerations for DevOps teams when implementing RWD.

    Ensuring Website Performance Across Different Devices

    One of the main challenges in implementing RWD is ensuring that your website performs well on all devices. This requires careful optimization of your website elements, including images, CSS and JavaScript.

    You also need to consider factors like loading speed and responsiveness, as these can significantly affect user experience. There are a number of available tools to help you analyze and optimize your website performance.

    Incorporating Responsive Design into CI/CD

    Continuous integration and continuous delivery (CI/CD) are key practices in DevOps. CI/CD involves integrating code changes regularly and delivering updates to users quickly and reliably. Incorporating responsive design in your CI/CD process can help you ensure that your application is responsive and user-friendly at all times.

    Automation in Testing

    Testing is a crucial part of the development process. With RWD, testing becomes more complex as your application needs to work on a wide range of devices and screen sizes. Automation can help streamline the testing process and ensure that your application is tested thoroughly and efficiently.

    User-Centric Approach

    A user-centric approach is essential in implementing RWD. This means considering the needs and preferences of your users at every stage of the development process. From the design phase to testing and deployment, the user experience should be at the forefront of your considerations.

    Monitoring and Troubleshooting Responsive Design Issues

    Finally, monitoring and troubleshooting are important aspects of implementing RWD. You need to monitor your website performance on different devices and troubleshoot any responsive design issues that arise.

    Analytics tools can provide valuable insights into how your website is performing on different devices. They can also help you identify and fix any issues that are affecting your website’s responsiveness.

    Conclusion

    In conclusion, responsive web design is an essential aspect of modern web development. It ensures your website is accessible and user-friendly on all devices, improving user experience and engagement. By understanding the principles of RWD and considering the key aspects of implementing it, you can unlock the power of responsive design and take your website to the next level.

  • Fortifying the Castle: A Quest to Secure the SDLC

    Fortifying the Castle: A Quest to Secure the SDLC

    Every business is a software business today. But as the pressure to churn out new applications and features grows, so do the chances of developers making mistakes. Tackling these challenges doesn’t just require more diligent developers, it requires continuous education across the software development life cycle (SDLC).

    To borrow a metaphor from Arthurian legend, it’s a never-ending battle against hidden risks and formidable adversaries. It will require security champions to share their wisdom and bring order to the kingdom.

    A Kingdom Under Siege

    These are dark times for those fighting the good fight. The threat landscape is a wild and unruly place where risk is everywhere, and adversaries often have the upper hand. They have the advantage of surprise and are masters at hiding in the shadows. But the threat is real. One vendor blocked over 146 billion threats last year alone.

    Many of these attacks take advantage of vulnerabilities in code. It’s a problem made more acute by the widespread use of open source components by today’s developer teams. One estimate suggested that last year alone, developers made 3.1 trillion requests for these components from the top four open source ecosystems. Yet many of these components contain vulnerabilities. According to the Linux Foundation, the average application development project features 49 vulnerabilities across 80 direct dependencies. Worse are the indirect dependencies that are far harder to track and, by some estimates, account for six in every seven project vulnerabilities.

    That makes software supply chain attacks and breaches far more likely, especially as threat actors are actively placing buggy components in upstream libraries with the hope they’ll be downloaded en masse. It’s also getting more likely because developers are coming under increasing pressure to deliver. It’s claimed that over half of developers handle a hundred times more code than they did a decade ago. And most are under pressure to write code faster. This increases the chance of mistakes happening, which in turn can cause significant financial and reputational damage.

    Fighting Back

    The answer to these mounting challenges has traditionally been to focus on “shifting left” or moving testing and scanning earlier in the SDLC. To ensure products are designed with security from the outset, it’s essential to follow “secure-by-design” principles. However, this is only half the picture. Scanning for vulnerabilities is certainly important, but even better is to ensure teams are building more robust code from the outset. Prevention is always cheaper and more effective than cure.

    This is where continuous secure coding education comes in. Continuous because technology and market demands are always changing. In this dynamic world full of risk, a one-and-done approach simply doesn’t cut it. Further, courses should be extended beyond the realm of the developer to every member of the SDLC team: From project management and UX specialists to QA, product management and beyond. All must share a common goal with a common responsibility to produce more secure code. Some will be security champions who share best practices with other stakeholders. But everyone must be pulling in the same direction.

    Time to Fortify the Castle

    So once the kingdom has assembled its diligent developers and security champions, what’s next? With the knowledge and skills imparted through continuous training, plus additional automated checks, real progress can be made to enhance security and resilience.

    If you’re familiar with the OWASP Top 10, you’ll recognize concerns such as server-side request forgery, misconfiguration, using vulnerable components and shortcomings in security logging, cryptography and software integrity. A stronger focus on foundational security practices like the principle of least privilege, separation of concerns and layered defense can mitigate these risks. Among the most prevalent threats are injection attacks, which include SQL injection and cross-site scripting. However, by using tools and having developers well-versed in strategies like input validation, parameterized queries, data cleansing and secure LDAP queries, these threats can be effectively addressed.

    Above all, it’s important to remember that everyone has a part to play in fortifying the castle, in protecting the kingdom from a mounting and formidable agglomeration of threats. That means, as a baseline, that everyone should be getting some form of continuous secure coding training. There’s no time to waste.