devopsy.kinsta.cloud

Category: IT as Code

  • NETSCOUT Taps F5 to Optimize Custom App Performance

    NETSCOUT Taps F5 to Optimize Custom App Performance

    Through its alliance with F5, NETSCOUT Systems has extended the reach of its nGeniusOne enterprise performance management platform to support custom applications.

    The nGeniusONE platform supports more than 1,000 voice, video and business data applications using NETSCOUT InfiniStreamNG appliances in combination with nGeniusONE to provide visibility into any infrastructure environment, including data centers, private and public cloud and co-location facilities. The integration with F5 extends those capabilities to add support for custom applications via integration with F5 BIG-IP server pool definitions that can now be directly imported into nGeniusOne.

    Eileen Haggerty, area vice president for enterprise product and solutions marketing for NETSCOUT, said that approach enables nGeniusOne to access clear, unencrypted traffic from the BIG-IP Local Traffic Manager.

    As more cloud-native applications built using microservices are deployed across distributed computing environments, network latency is becoming a bigger DevOps challenge. A wide range of networking issues can adversely impact application performance, but without any visibility into network traffic, it can be challenging to determine the root cause of an issue. NETSCOUT has deployed a global network of appliances to surface those issues.

    A recent report published by Cloud Security Alliance (CSA) found the average enterprise uses 464 custom applications and expects to deploy 37 new applications in the next 12 months. At that rate, the number of organizations likely to encounter networking issues is only going to increase, noted Haggerty.

    It’s not clear to what degree network operations (NetOps) teams are becoming integrated with DevOps teams that build and deploy custom applications. The need for both teams to collaborate more effectively is becoming more apparent as more application code is deployed at the network edge. In some cases, developers are now programmatically invoking network resources directly, while other organizations provide developers access to a portal to self-service their requirements within the context of a set of pre-defined guardrails. Regardless of approach, the need for greater visibility into the underlying networks that custom applications depend on has become critical.

    Exactly how much that need will drive organizations to embrace one networking vendor over another remains to be seen. DevOps teams are starting to exercise more influence as organizations realize how much they depend on custom software to drive digital business processes. DevOps teams need to be able to understand whether an issue is the result of a networking problem or an inherent problem with the code written or the way an application has been deployed.

    Of course, DevOps and NetOps teams don’t share a common nomenclature so the cultural divide between these teams can be wide. The simpler it becomes for NetOps teams to share visibility into networking services the easier it becomes to bridge that divide. Developers should be able to see for themselves how changes to application code might potentially improve network performance. In the absence of any proof to the contrary, most DevOps teams will simply assume there is a fundamental flaw in the networking services being provided.

  • GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian published an analysis of more than one billion commits to GitHub repositories that found 10 million occurrences of secrets, with one out of 10 developers exposing a secret.

    Mackenzie Jackson, a developer advocate for GitGuardian, said more than 80% of all the secrets caught by live monitoring GitHub were exposed through personal repositories, with a large share of them being corporate secrets. In fact, three million of the secrets discovered were unique instances, with 5.5 commits out of every 1,000 made exposing a secret.

    On a year-over-year basis, the report also found that the number of hard-coded secrets discovered in these repositories increased 67%. More than half the secrets discovered (56%) contained a generic password.

    There appeared to be no correlation between developer experience and the number of secrets exposed. Junior and senior developers are equally predisposed to making the same mistakes, said Jackson. The most common mistake is secrets left exposed because developers used them to simplify access to components and resources when building their applications and then forgot to remove them when the application was deployed in a production environment.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. The issue with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have issues with how secrets are managed could be staggering.

    In theory, at least, the adoption of DevSecOps best practices should be mitigating this issue, but as the volume of code stored in repositories continues to increase, it would appear more fundamental mistakes are being made. Cybercriminals, meanwhile, have a greater appreciation today for weaknesses in software supply chains, so many of them are scanning repositories for secrets that will enable them to breach an application.

    Of course, there’s a lot more attention being paid to secure software supply chains, especially in the wake of the Biden administration creating a National Cybersecurity Strategy that requires Federal agencies to, among other things, lock down software development life cycles on an end-to-end basis. Most enterprise IT organizations, if they have not done so already, are expected to follow suit.

    As a result, DevOps teams should expect to see more cybersecurity professionals focusing more on secrets management. Developers, naturally, will not want to be called out for mismanaging secrets, so over time, the overall state of application security should steadily improve. The issue, of course, is the volume of attacks against software supply chains is expected to increase. Many previous mistakes are likely to come back and haunt developers and the organizations that rely on their code and wreak havoc downstream.

  • Cisco Streamlines Licensing Options for IT Operations Platform

    Cisco Streamlines Licensing Options for IT Operations Platform

    Cisco has reduced the number of licensing options for its Intersight operations platform to two as part of an effort to make the software-as-a-service (SaaS) platform for managing on-premises and cloud computing environments more accessible.

    In addition, Cisco has added a Cisco UCS X-series Modular System to its portfolio based on a two-socket server configured with 4th Gen Intel Xeon Scalable processors and an instance of Intersight that has been extended to make it possible to apply policies that limit energy consumption.

    Mahesh Natarajan, senior director of product management of cloud and compute for Cisco, said Intersight is a complement to the management platform the company already bundles with its Unified Compute Systems (UCS) platforms for on-premises IT environments.

    Essentials enables management of server profiles/policies, managing firmware updates and proactive health monitoring and security advisories along with many other capabilities. The Advantage option adds low-code/no-code orchestration, more advanced server operations, multi-domain visibility and third-party integration with, for example, third-party IT service management (ITSM) platforms.

    In the wake of the COVID-19 pandemic, there’s been a shift toward cloud-based platforms that make it simpler for IT teams to centrally manage multiple IT environments from anywhere. Cisco Intersight, in addition to supporting Cisco servers, has been integrated with cloud services from Amazon Web Services (AWS), Google and Microsoft to achieve that goal.

    In fact, as the management of IT continues to converge across multiple platforms, the concept of a data center has become something of a misnomer, said Natarajan. Integrated application workloads are now routinely distributed across on-premises and cloud computing platforms that are simpler to manage using a consistent set of policies, he added.

    A SaaS platform also provides the added benefit of reducing the total cost of IT because the need to deploy management platforms for each environment is sharply reduced, noted Natarajan.

    Very few organizations are running all their application workloads in one environment, so the need to reduce costs by finding more efficient ways to manage IT operations is becoming a more pressing issue. Most IT teams are trying to limit the number of full-time employees they might otherwise hire by trying to improve the overall productivity of the teams they do have.

    Of course, centralizing the management of IT is as much a cultural challenge as it is technical. Each IT team that deploys a workload on a platform has a natural bias toward using the management framework made available by the platform provider. Each of those platform providers is now extending its reach as part of an effort to become the one control plane that rules them all. Cloud service providers, for example, are extending the reach of their management frameworks into both local data centers and edge computing environments.

    Regardless of preferences, the cost of licensing multiple management platforms can quickly become prohibitive, especially if they provide redundant capabilities. Organizations looking to reduce the total cost of IT would much rather reduce licensing costs than lay off the IT staff that drive a wide range of digital processes. The challenge, as always, is getting everyone in the IT organization to agree on what that one management platform should be.

  • Zenhub Brings Issues Management to Project Management Platform

    Zenhub Brings Issues Management to Project Management Platform

    Zenhub today announced it is adding an issue management module that makes it simpler for stakeholders to collaborate with developers on application development projects without having to log into a GitHub repository.

    Fresh from raising an additional $10 million in capital, Zenhub co-founder Aaron Upright said Zenhub Issues is a plug-in for a project management application the company developed for GitHub environments to better streamline software development life cycles. The issue is that many application stakeholders, such as marketers, are not especially pre-disposed to logging into a repository for managing software components, he said.

    Zenhub Issues provides an alternative means for collaborating with developers that doesn’t require stakeholders to log into GitHub, he said. In addition, organizations no longer need to acquire additional GitHub licenses for those users, noted Upright. Many of those end users wind up with read-and-write access to software components, which creates unnecessary cybersecurity risks should their credentials be compromised, he noted.

    In some cases, organizations will also be able to eliminate the need for the project management applications many of those stakeholders have adopted because they can track issues via Zenhub Issues, he added.

    Many organizations’ entire business strategies now revolve around accelerating the rate at which software development projects can be completed. Many elements of those projects, however, can’t go forward until a specific component upon which it depends is completed, so project management has become a critical function. Investors are holding business leaders more accountable for software delivery timetables that have direct implications on revenue generation, so that pressure naturally falls on DevOps teams.

    It’s not surprising that there aren’t a wider range of end users of project management applications as various stakeholders seek to keep closer tabs on how updates to schedule impact their planning cycle. Everyone from the sales team to the board of directors now wants more visibility into the rate at which software development projects are being completed. The challenge DevOps teams face is that software development is an inexact science. Application development projects can just as easily fall behind schedule as they can leap ahead depending on how well code is written.

    Regardless of how application development projects are managed, the relationship between DevOps teams and the rest of the organization has fundamentally changed. Unfortunately, expectations are not always realistically aligned with available development resources. A project management application that is widely employed across an organization should make that apparent to all interested stakeholders. In theory, at least, that should result in either the hiring of additional developers or a reassessment of the business strategy.

    One way or another, project management applications designed for managing software development projects now play a pivotal role in business planning. The challenge is finding a way to populate those applications with the data needed without requiring developers to help enter data that can already be easily pulled from the DevOps tools and platforms. Otherwise, instead of being viewed as a benefit, the entire project management process becomes one more tedious task that development teams are not going to prioritize over writing code.

  • IT Teams Need to Do More With Increased Budgets

    IT Teams Need to Do More With Increased Budgets

    A survey of 600 C-suite and IT decision-makers published today found the majority of organizations are trying to make increased IT budgets stretch even further as costs rise and the number of workloads deployed continues to increase steadily.

    Conducted by SoftwareOne Holding AG, a provider of software and IT services, the survey found 93% of respondents expected IT budgets to increase, with 83% planning to invest more in application modernization. However, 83% also noted they are under pressure to stretch budgets even further as part of an effort to increase agility (46%), improve customer experience (45%) and improve security to support remote workforces (45%). A full 92% said they would be increasing investments in security.

    The core issue that IT leaders are wrestling with appears to stem from increased cloud costs. The survey found the primary causes of those increased costs are inflation-related price hikes passed along by cloud service providers (41%), workloads exceeding planned capacity (40%), transformation initiatives that are cloud-dependent (40%), fewer cloud discounts (37%), lack of visibility into and management of cloud costs (34%), overprovisioning (34%), repercussions from previous lift and shift efforts (34%) and shadow IT (30%).

    Craig Thomson, senior vice president of cloud and application services at SoftwareOne, said that technical debt is having a significant downstream impact across organizations. For example, the survey found 72% of respondents reported that digital transformation initiatives are falling behind, with 38% noting the accumulation of this debt stems from rushed cloud migrations throughout the pandemic. Just under a third (31%) failed to optimize workloads before commencing the migration. More than a third (38%) admitted their organization miscalculated the cloud budget.

    Progress is being made, however, with 45% of respondents reporting they have improved transparency and control of cloud costs. A full 80% planned to increase their investment in financial operations (FinOps) to achieve this, and 39% said they would use cloud-native tools to reduce licensing costs.

    Those efforts suggested IT leaders are being very deliberate in their approaches to reining in costs while at the same time embracing best practices, said Thomson. IT leaders have finally started to realize the cloud is not so much a destination for workloads as much as it is an operating model, he added.

    The challenge is that cloud computing environments are becoming more complex to manage as organizations deploy cloud-native applications on Kubernetes clusters and serverless computing frameworks deployed alongside legacy monolithic applications that were lifted and shifted to the cloud. Organizations will need to invest more in automation to make up for an IT talent gap that prevents organizations from accelerating the rate at which they can build and deploy cloud applications, noted Thomson.

    On the plus side, it appears organizations are willing to allocate budgets to achieve their IT goals. The issue is that, as more organizations become more dependent on software, they are asking IT teams to do even more with the resources at hand. The degree to which that can be achieved, of course, is almost wholly dependent on how much of the technical debt that already exists in the cloud can be retired.

  • Tips For Securing CI/CD Pipelines

    Tips For Securing CI/CD Pipelines

    Most development teams want to increase the pace of their software delivery. As such, continuous integration and delivery (CI/CD) has grown in importance, helping push code from build to production as seamlessly as possible. CI/CD pipelines often loop in many elements and may comprise a diverse stack of tools, automations and various languages. But because of this, the attack surface can be large. And as gaps in the CI/CD toolchain emerge, so do security concerns.

    In recent years, we’ve seen several high-profile cases where CI/CD environments were compromised. For example, take the Circle CI breach, in which a bad actor accessed Circle CI production systems. Others include the compromise of the SolarWinds build system and the Codecov breach. CI/CD security issues are alarming because so much control and automation are given to a pipeline. Unauthorized CI/CD access could be leveraged to publish malicious code or steal sensitive information.

    I recently met with Daniel Krivelevich, co-founder and CTO of Cider Security (acquired by Palo Alto Networks), to better understand the risks facing modern CI/CD. Krivelevich is a seasoned CI/CD security expert and co-author of the Top 10 CI/CD Security Risks framework, which OWASP adopted in late 2022. According to Krivelevich, there is a general lack of knowledge and visibility into these risks. “The CI/CD ecosystem as a whole is full of holes and opportunities for attackers,” he said.

    Below, we’ll review some of the risks that CI/CD pipelines face and offer general ways to mitigate some of these concerns. Hopefully, with greater security awareness around CI/CD threats, both tooling providers and users can begin to diffuse the potential of attacks against their systems.

    The Top Concerns Facing CI/CD Security

    The OWASP Top 10 CI/CD Security Risks framework covers the most impactful risks within modern engineering systems and gaps in CI/CD. It was informed by analyzing many attacks in recent years and was compiled with insights from numerous experts. Krivelevich hopes the framework will spark discussions around the mindset defenders should have when they’re looking to protect the modern engineering ecosystem. The top 10 risks are as follows:

    • CICD-SEC-1: Insufficient Flow Control Mechanisms
    • CICD-SEC-2: Inadequate Identity and Access Management
    • CICD-SEC-3: Dependency Chain Abuse
    • CICD-SEC-4: Poisoned Pipeline Execution (PPE)
    • CICD-SEC-5: Insufficient Pipeline-Based Access Controls (PBAC)
    • CICD-SEC-6: Insufficient Credential Hygiene
    • CICD-SEC-7: Insecure System Configuration
    • CICD-SEC-8: Ungoverned Usage of Third-Party Services
    • CICD-SEC-9: Improper Artifact Integrity Validation
    • CICD-SEC-10: Insufficient Logging and Visibility

    Before an organization can dissect these individual risks, however, they must overcome an even bigger problem—a critical lack of understanding regarding the CI/CD ecosystem and the many elements under the hood. Since CI/CD is not traditionally viewed as a security risk, this can result in insecure default configurations, insecure processes and systems not adopting a secure-by-design approach.

    “There’s a big gap between the level of understanding and opportunities attackers have and the knowledge defenders have over what attackers can do,” said Krivelevich. “Organizations traditionally have not been proactive enough in understanding this, unlike other elements that are more traditionally recognized as part of the attack surface. The main gap is a mindset shift.”

    Tips to Secure CI/CD

    So, knowing the above risks, what are some best practices to secure CI/CD pipelines? Krivelevich shared some tips to keep in mind.

    Bring CI/CD under the security umbrella. First, realize that CI/CD should be scrutinized. This will require an awakening in the community and more proactive effort than before. Krivelevich encouraged development teams to place it on their roadmaps and think about it.

    Map the attack surface. Before implementing security measures, you need to know what you’re protecting. Therefore, it’s a good idea to map your CI/CD environment and produce an inventory of assets. Cataloging the total surface area of dependencies and integrations is necessary to understand risks and helps mitigate CICD-SEC-10: Insufficient Logging and Visibility.

    Keep this updated regularly. Since the cadence of change is fast, teams will want constant visibility into their ecosystem and what’s under the hood. This may even lead to shadow IT, as per CICD-SEC-8: Ungoverned Usage of Third-Party Services. Therefore, Krivelevich recommended keeping a regularly updated inventory. This means continually mapping control systems, container registry artifacts, plugins and all other assets used as part of CI/CD.

    Protect the software supply chain. Many building blocks make up the modern software delivery process. But, some dependencies may be abused or contain malicious code, as per risk CICD-SEC-3: Dependency Chain Abuse. Dependencies within the CI/CD process may be prone to a host of open source vulnerabilities.

    Safeguard CI/CD credentials. CI/CD tools “possess secrets to most sensitive crown jewels in an organization,” Krivelevich explained. Therefore, access tokens and secrets related to CI/CD tools should be protected to avoid costly credential leaks. A zero-trust approach to CI/CD could help avoid CICD-SEC-2: Inadequate Identity and Access Management.

    By creating a virtual heat map of areas to address, organizations will be more informed and better equipped to assess risk. And according to Krivelevich, by implementing these best practices, defenders have a lot of power to raise security expectations in the CI/CD space. “When defenders and users become more diligent about security, the requirements from vendors will increase.”

    CI/CD is the Beating Heart, Don’t Let it Break

    “The engineering ecosystem and pipelines themselves are the beating heart of engineering,” said Krivelevich. And as this system becomes a larger part of what makes a business tick, it will be more heavily relied upon for mission-critical tasks and retaining agility.

    Yet, many building blocks comprise the contemporary software delivery process, and CI/CD pipelines can be a risky area due to the number of systems they touch. Further complicating things is the fact that the delivery ecosystem wasn’t traditionally viewed in security terms. This combination of many opportunities and limited security oversight makes CI/CD lucrative for attackers.

    Rectifying the top 10 risks is a relatively easy gap to address, said Krivelevich—what’s not so easy is the mindset shift required to take CI/CD security seriously. Organizations that invested deeply into microservices and rapid engineering processes will most likely be more susceptible to attacks, he added, since they typically use a diverse array of tools and a complex, integrated delivery process.

  • Good Things Happen When DevSecOps and Cloud Collide

    Good Things Happen When DevSecOps and Cloud Collide

    The marriage of cloud and software development is arguably the heart and soul of digital transformation. Providing pathways to greater efficiencies, lower costs and greater enterprise performance, the duo is poised to fundamentally transform industries as we know them. The compounding complexities of hybrid cloud operations and software supply chains, however, have led to a greater risk of vulnerabilities, errors and attacks.

    Increasingly wrapped around microservices, containers and orchestration platforms, the complexities of cloud expansion and software development couldn’t be more intertwined or expose more complicated risks than they do today.

    Software: A World of Consistent Change

    The state of software development is one of consistent change. Whether we call it agile or adaptive matters far less than the need to infuse operations with a new mindset and culture about the need for continuous development. Increasingly that includes the infusion of security disciplines and technologies directly into the main artery of that development.

    Enter DevSecOps, an approach to software that integrates security initiatives at every stage of the software development lifecycle to deliver high-performing secure applications.

    The cause is not lost on the National Institute of Standards and Technology (NIST) and its cybersecurity center of excellence (NCCoE) which has announced a DevSecOps project dedicated to “developing and documenting an applied risk-based approach and recommendations for secure DevOps and software supply chain practices consistent with the secure software development framework (SSDF), cybersecurity supply chain risk management (C-SCRM), and other NIST, government, and industry guidance.”

    This is a far cry from software development of old. According to CTO Emeritus, Hu Yoshida, “Software, once the product of developers confined to writing long lines of code for specific applications, is now an exercise of integration – an amalgamation of third-party components provided by a variety of vendors, cloud providers, and open source software (OSS) groups. In fact, today, as much as 90% of code comes from such outlets, creating a software supply chain.”

    Although these new processes provide great advantages in terms of access to innovation and faster development cycles, the addition of external touchpoints and third-party software increases the risk of flaws, mistakes, and vulnerabilities. These risks only rise further when considering their deployment, usage, and management across complex hybrid cloud environments.

    How to Take Advantage of the Collision

    Cloud-based data is accounting for 39% of successful cyberattacks. Containerized applications, which have been a boon to both migration and management can also lead to vulnerabilities – which is fitting for security to be cited as a top concern for more than half of the organizations surveyed.

    From business continuity to business performance, organizations must begin assuming a security posture that considers the rising confluence of cloud management and software development.

    The idea is simple: You must find a way, a process, a method, and the right partners to help secure all workloads across any cloud environment, regardless of the platform or the amount of data and application real estate needed.

    By establishing this model, organizations are able to create a fundamental layer of protection against the ever-evolving threat of cybercriminals. Take one of our large banking customers, for example, who runs critical applications on AWS with stringent security and compliance requirements. We implemented a secured framework to protect their applications running on modern, cloud-native services like containers and Lambda functions using DevSecOps principles and cloud-native SIEM solutions. This enables them to scale their business in the cloud without worrying about compliance violations.

    One of our large pharmaceutical customers with a very large presence in both AWS and Azure experienced challenges keeping their cloud security posture in pace with the growing business demands on the cloud, increasing risk to the environment. By establishing a security process using cloud security posture management, we were able to significantly reduce cloud misconfigurations and auto-remediate several cloud vulnerabilities proactively to improve the security posture of the environment.

    The bottom line is that building security into the workloads will provide a fundamental layer of protection. The collision of cloud and DevSecOps is real. Organizations would be wise to realize it and take advantage of it to dramatically improve business performance and resiliency.

  • Survey: More Cybersecurity Pros Embedded in DevOps Teams

    Survey: More Cybersecurity Pros Embedded in DevOps Teams

    A survey of 2,500 C-level executives published today by Palo Alto Networks found 81% of organizations have embedded cybersecurity professionals within their DevOps teams.

    Despite the presence of those cybersecurity professionals, however, the survey also suggested there is much work to do in terms of optimizing DevSecOps workflows. A full 90% of organizations cannot detect, contain and resolve cybersecurity threats within an hour, the survey found.

    Bob West, chief security officer for Palo Alto Networks, said most of the challenges associated with DevSecOps are directly related to persistent cloud security issues. More than three-quarters of organizations (78%) said they had distributed responsibility for cloud security, but almost half (47%) said a majority of their workforce still does not understand their security responsibilities.

    In many cases, developers with little to no cybersecurity expertise are responsible for provisioning cloud infrastructure. As a result, misconfigurations that create security issues are commonplace, noted West. That’s especially problematic because three-quarters of organizations (75%) are deploying new or updated code to production weekly, with almost 40% committing new code daily, the survey found. Given that developers far outnumber cybersecurity professionals in most organizations, it remains challenging to ensure application code is secure, noted West.

    In addition to improving the overall state of cloud security, organizations need to focus on fundamentals such as training developers to be more mindful of cybersecurity issues, he added. Most developers never had any formal cybersecurity training, so it’s up to organizations to make sure that particular skills gap is closed, he noted. In addition, organizations need to make sure they have a robust set of patch management processes in place alongside a capability to manage permissions and entitlements, added West.

    Overall, the survey found organizations are using more than 30 security tools, on average, including six to 10 dedicated to cloud security. More than three-quarters of respondents (76%) said relying on multiple security tools created blind spots that affected their ability to prioritize risk and prevent threats. A full 80% said they would benefit from a centralized security solution that sits across all of their cloud accounts and services.

    One way or another, a rising tide of regulations focused on improving the security of software supply chains will force organizations to improve cloud security, said West. The survey showed there is a strong commitment in terms of making cybersecurity professionals an integral part of a DevOps workflow. The issue is that there are still a raft of training and process issues that need to be addressed at a time when cybercriminals are becoming increasingly adept at compromising applications both as they are developed and after they are deployed.

    Of course, training and modifying processes take time. DevSecOps is as much about changing culture as it is about acquiring new tools. DevOps teams are still highly committed to building and deploying applications as quickly as possible. The challenge is finding a way to insert a set of cybersecurity gates within those workflows without slowing down the pace at which applications are developed.

  • AWS Delivers on Latest Graviton3 Price/Performance Promise

    AWS Delivers on Latest Graviton3 Price/Performance Promise

    Amazon Web Services (AWS) has expanded the number of virtual machines based on the latest generation of its Graviton processors to include instances that support DDR-5 memory.

    The latest Amazon EC2 instance types, dubbed M7g and R7g, that are now generally available are based on the AWS Graviton3 processors developed using an architecture created by Arm. Previously, these instances were only available as part of a technology preview program.

    Rahul Kulkarni, director of product management at AWS, said these latest offerings take advantage of DDR-5 memory to provide 25% better performance than the previous sixth generation of Graviton instances. DDR5 memory increases the amount of bandwidth available by 50%, he noted.

    Graviton processors now provide the lowest-priced instance of virtual machines in addition to the best performance and overall price/performance across the AWS portfolio, Kulkarni added.

    AWS is making a case for employing its AWS Graviton processors for general-purpose workloads as more IT teams are being tasked with reducing costs as the overall number of applications being deployed in the cloud continues to increase. In fact, all of the top Fortune 50 companies have already deployed workloads on Graviton processors, noted Kulkarni.

    While it’s not clear how many applications are being developed to run natively on Arm processors, the process of refactoring existing applications to run on Arm processors is not as intensive for most applications as it was when previously moving applications from one class of processors to another.

    In addition, Kulkarni noted AWS has committed to providing a full range of DevOps services, including a continuous integration/continuous delivery (CI/CD) platform, to help facilitate any transition to Graviton processors.

    There are, of course, multiple strategies for containing cloud costs that range from committing to consuming a specified amount of compute resources annually at discounted rates to relying more on spot instances that are available for limited amounts of time. Regardless of approach, the days when developers were allowed to invoke cloud resources at will appear to have come to an end as enterprise IT organizations become more aware of the total cost of IT. As a result, many of them are adopting financial operations (FinOps) best practices to maximize the utilization of cloud infrastructure resources.

    AWS, like most cloud service providers, gives organizations a wide range of processor options. However, it’s apparent that AWS views Arm processors in the form of Graviton to be the most efficient from both a price and performance perspective. It’s not clear how quickly organizations are embracing Graviton in the cloud given the dominance of x86-based platforms, but it’s apparent there is now a clear alternative for general-purpose workloads. If fact, the more data-intensive those workloads become, the greater the interest in more efficient processor architectures.

    Of course, x86 platforms are not going away anytime soon. But as more Arm-based processors find their way into the enterprise, DevOps workflows will only become more challenging to manage.

  • Five Tips for Moving IT Ops to DevOps

    Five Tips for Moving IT Ops to DevOps

    The era of siloed development and operations functions is rapidly coming to an end. The concept of DevOps has already closed the gap between IT and developers, but as I speak with customers around the globe, one theme continues to arise. Many systems administrators are ill-equipped to handle the shift from IT Ops to DevOps and, in some cases, don’t even know the right questions to ask to ensure they are planning accordingly.

    Having the appropriate equipment and software in place means nothing without people trained and ready to implement the shift from IT Ops to DevOps. As IT strives to support and protect developers continuing to innovate with wild-west-style creativity, how can we empower them with the tools and knowledge to ease the transition? This starts with asking the right questions, but requires IT to think about new things: Automating processes, revamping config management, building efficiencies in data orchestration and standardizing a set of APIs with enterprise-level protections.

    Asking the Right Questions About DevOps and Infrastructure-as-Code

    Enterprises need to look holistically at how infrastructure services are created, delivered and managed. Continuing current practices, such as manual provisioning complicated by different interpretations of imprecise instructions, will continue to lead to snowflake architectures and brittle systems. Organizations must modernize or replace this existing infrastructure to exploit cloud architectures and implement true platforms, actualizing the promise of the cloud.

    Infrastructure-as-code is an underlying framework that removes the manual process of managing and provisioning resources and opens doors to enabling DevOps. Using code to define the infrastructure configuration means that there is greater consistency between platforms. That consistency allows IT to seed the agile processes, methods and technical approaches needed to evolve a DevOps culture.

    To get to a point where infrastructure-as-code is facilitating a DevOps culture, it’s important for IT Ops to understand how to develop an early-stage continuous delivery and deployment pipeline. They also need to begin to seed practices and values native to DevOps for software engineering principles and practices with IT Ops. It’s also important to define success criteria–referred to as the “definition of done” in agile and begin to think about how to implement the infrastructure-as-code using DevOps best practices.

    Don’t Expect Developers to Become Expert Sysadmins

    Developers don’t want or need an extra layer of oversight or management, nor do they want to ask for permission before doing what they do best: Innovating. DevOps can more rapidly provision compute and storage resources and provide infrastructure-as-code while automating DevOps processes, empowering developers to become an innovation engine for their businesses.

    So much of what we’ve seen puts pressure on IT to be proactive when protecting developer cycles in containers and beyond. The NSA, as well as other industry data protection companies, offer tips for IT to stay ahead of these threats, but manual patching and scanning is not only handcuffing IT but stifling innovation in DevOps. The challenge is that IT can’t move as fast as developer cycles and often lose sight of what developers are putting into containers or other IT environments.

    While global data protection restrictions might have an impact on things like machine learning and AI from a consumer experience standpoint, it does not affect how IT might use these technologies to automate protection. It’s also not about extending protection to developer workloads, it’s about having an environment that recognizes and automates protection against threats in all environments. This way, developers and IT don’t have to become system admins or data protection experts. They can focus on the innovation at hand.

    Config Management is Critical to Empowering Developers

    As we continue to prioritize the automation of processes in the developer environment, it’s also important to consider how to move beyond just automating protection and infrastructure while allowing IT Ops to still have an eye on identifying, documenting and tracking changes in the DevOps stack. To do this, DevOps should look to configuration management tools to help manage and automate the architecture through strong community support, customization, scalability and the simplification of complex configurations.

    These tools, such as Ansible, Terraform, etc., can be deployed to meet specific needs and preferences. The point is, once you create infrastructure-as-code, you need a way to configure and manage it that fits the model that’s appropriate for your business. While you can use IaC to configure and manage, you still need to determine how to best implement automation and configuration in the most appropriate environment.

    Data Orchestration Eliminates Repetitive Cycles

    Data orchestration tools bring all data together regardless of where it originates or its format. An ecosystem that can collect data efficiently and convert it to a format that is easily understood by any and all endpoints is critical to the app development process. There’s no need to iterate at multiple levels, on multiple platforms or in different environments. IT can enable developers to innovate and learn from any environment, data warehouse or platform and build applications that can do the same.

    In the same way data orchestration can drive efficiency, there are additional benefits. Automating the collection, analysis and formatting of data saves IT countless hours of doing these processes manually. While there are obvious cost benefits, there are also a few other important benefits.

    To allow developers to continually innovate at a wild west pace, IT/DevOps must also ensure they can meet data privacy compliance and governance policies. Data orchestration allows businesses to delete or store data based on policies preset in the environment. It also allows businesses to ensure that internal policy is upheld throughout the development process. Orchestration then takes that data and makes it workable so that any iterative process can be applied without fear of bottlenecks or additional cycles.

    Standardized APIs Trump Those Created by Unaffiliated Coders

    Today’s developer profile expands far beyond the enterprise. In fact, according to Developer Nation, we can expect a whopping 45 million developers in the world by 2030. These numbers don’t include the unaffiliated coders working out of their basements or garages. That’s not to say that creativity isn’t appreciated or eventually adopted by industry leaders. But the code and software created don’t necessarily abide by enterprise governance and privacy standards. Yet we continue to see wild west developers pulling in anything and any kind of API to ensure it meets the needs of the next business application they are developing. How does IT police this?

    They don’t have to. For IT/DevOps to identify a set of APIs that meet business imperatives and certify them for use within the organization is imperative. Think about a scenario in which a developer has not only a comfortable environment to sit in without learning new skills but also an environment that automates protection, orchestration and gives them a preset library of helpful and open APIs. Businesses can begin to focus on delivery rather than policing and upskilling developers to work within the confines of the business ecosystem.

    As data continues to flow in and out of organizations and more data is being created and stored at the edge, a DevOps culture built for tomorrow’s developers is critical. These tips are a great starting point to ensure you’re installing a future-proof culture of innovation. What are some of the obstacles you’ve faced and overcome during the transition to DevOps?