devopsy.kinsta.cloud

Category: Infrastructure/Networking

  • More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    A survey of 600 DevOps professionals conducted by strongDM, a platform for managing access to IT infrastructure, found nearly two-thirds (64%) had productivity impacted on a daily or weekly basis because of access issues.

    It’s not surprising that, as a result, DevOps teams created a number of workarounds to gain access, even though those methods don’t comply with cybersecurity best practices, according to the survey. More than half of respondents (55%) maintained backdoor access to systems, and 42% have embraced shadow IT to get access to tools and systems they needed for their roles, the survey found.

    Worse yet, the survey found that 53% of respondents admitted they are sharing credentials across teams.

    Well over half (57%) of respondents said it could take days or weeks for access requests to be approved, with 40% reporting it takes days to add tools to existing access solutions. Nearly three-quarters (73%) of respondents also noted it requires 15 minutes or more to gain access to infrastructure.

    More than half of respondents (52%) said they have missed deadlines due to issues with accessing infrastructure, with 53% of those respondents being held accountable for the missed deadline even if it was caused by their lack of access to infrastructure.

    Justin McCarthy, CTO for strongDM, said despite all the hype surrounding identity management and zero-trust IT, it’s clear many organizations are still struggling with the basics of access control. That issue has been further exacerbated by the need to enable more DevOps professionals to work from home since the start of the COVID-19 pandemic more than two years ago, he added.

    Many of those organizations are still relying on virtual private networks (VPNs) even though it’s been shown that stealing the credentials to access those VPNs is relatively trivial, McCarthy added.

    In place of those approaches to access IT infrastructure, strongDM is making a case for a dedicated infrastructure access platform that manages and audits access to databases, servers, clusters and web apps. It is based on local client software, a gateway intermediary and configuration tools that track roles and permissions.

    The benefits of that approach span everything from lower IT support costs to faster onboarding of new IT staff, noted McCarthy.

    Managing infrastructure access for DevOps teams is, of course, always going to be a challenge. DevOps teams are made up of engineers—among the most challenging types of end users to support. Many of them will use their own expertise to circumvent any process they deem to be inefficient. The trouble is, many of those end-runs would not pass muster with cybersecurity teams responsible for access management. The challenge each of those cybersecurity teams needs to come to terms with is the amount of time they want to spend time looking for these cybersecurity policy workarounds versus making it easier to securely access IT infrastructure.

    The sad truth is both DevOps and cybersecurity professionals are wasting a lot of time and effort trying to outwit each other when that time could be put to better use.

  • Survey Sees Alternative Cloud Service Providers Gaining Ground

    Survey Sees Alternative Cloud Service Providers Gaining Ground

    A survey of 458 development professionals, managers and senior leaders conducted by Techstrong Research, a sister entity of DevOps.com, found 43% are considering adding additional cloud service providers in the next 12 months. In total, nearly two-thirds said they are at least considering, evaluating or are ready to buy from a trusted alternative cloud vendor, with 20% reporting they have already contracted one.

    The survey, conducted on behalf of Linode, an arm of Akamai Technologies that provides cloud services, found a full 93% of survey respondents are already using either Amazon Web Services (AWS), Microsoft Azure or Google Cloud Compute Platform (GCP). Nearly two-thirds (65%) reported they already used more than one cloud service provider. More than a quarter (28%) said they are using alternative providers to augment services they consume from either AWS, Microsoft, Google, Oracle, IBM Rackspace or Alibaba. And 19% said they are using a hyperscaler and an alternative cloud service provider.

    The biggest drivers respondents cited for using alternative providers are reducing reliance on a single provider (55%), improved price/performance (38%) and recent cloud outages (31%).

    Respondents also said they are concerned that large providers might one day compete with them as they expand their reach into other industry segments (24%) or may engage in business practices that would create a moral conflict (19%). A quarter (25%) said they already viewed their cloud service provider as a competitor.

    Dan Kirsch, principal analyst for Techstrong Research, said as cloud computing continues to mature, it is becoming apparent that more organizations are considering their options when it comes to consuming commodity compute, storage and networking services. Many organizations simply don’t need to access complex cloud services, he noted. A total of 42% of respondents said a cloud service provider offering core infrastructure primatives could handle 90% of their typical workloads. In many cases, alternative cloud service providers are being used to augment rather than replace a hyperscale cloud service provider, noted Kirsch.

    Overall, nearly three-quarters of respondents (74%) said they expect their infrastructure will be cloud-based by the end of this year. Nearly three-quarters of respondents buy cloud services directly from an infrastructure provider, with the rest employing a managed services provider or some other type of third-party cloud services reseller.

    More than one-third of respondents also reported using a payment mechanism other than a contract or request for proposal (RFP), according to the study. Among customers of alternative cloud providers, more than two-thirds (67%) are using some other payment mechanism, with one-quarter using cryptocurrencies to pay. That option is becoming increasingly important because more organizations are looking for ways to reduce costs by employing alternative payments, said Kirsch.

    In other cases, IT professionals are looking for an end-run around cumbersome purchasing processes or simply opt to use alternative payment methods as a matter of personal preference, he added. Alternative providers, as a general rule, are more open to processing these types of payments, noted Kirsch.

    The shift to the cloud has clearly been accelerating since the start of the COVID-19 pandemic. But as the landscape continues to evolve, there are now more options than ever for IT organizations to consider as the cloud becomes the preferred platform on which to deploy applications.

  • How to Manage and Engage Remote Engineering Teams

    How to Manage and Engage Remote Engineering Teams

    As engineering teams look to remain remote or hybrid, executives need to fundamentally change how these teams are managed. After tackling the tactical aspects of a distributed workforce—like home office equipment, a comfortable space where employees can get work done and reliable meeting, calendar and communication tools—more nuanced issues come into play.

    Before the COVID-19 pandemic, when a minority of engineering team members worked remotely, those team members knew that they needed to make a concerted effort to connect and to be part of the group. When the majority are remote, however, the expectations of offsite employees have shifted dramatically. For organizations that had built their business with an in-person team, this brings up entirely new questions of communication, culture, loyalty, problem-solving and retention to the forefront.

    Fundamentally Shifting Engineering Team Structure

    Inspiring change requires fundamental shifts in the ways engineering teams work. Our own engineering teams have experimented with some changes that have proven effective, including:

    • A globally revised team structure that embraces a culture of autonomy and breaks larger engineering teams into smaller groups. Smaller groups help engineers feel more engaged, valued and empowered; it keeps meetings short and focused and allows for more parallel streams of work.
    • Overhauling our design process to get a champion or ‘anchor’ from the dev team involved in key features early on. This anchor is responsible for translating product and design requests into technical specs and is the de facto technical lead of the feature. Having this role rotate between team members for each feature means each member gets a chance to grow their skills as a technical lead.
    • Assigning dedicated designers to smaller groups to empower them to make small adjustments mid-flight. This would allow standups to operate as mini working sessions to iron out technical details that would normally be resolved through ‘shoulder taps’ or in-person quick questions.
    • Placing a strong emphasis on sprint retros as a way to make real changes to the way work gets done. When used in conjunction with an initiative to empower devs, sprint retros became a powerful tool to get dev feedback on improving the process.
    • Keeping teams accountable by encouraging transparency and clear communication as a tradeoff for their autonomy. We encouraged note-taking and regular updates, as well as clear goal-setting from the teams at the beginning of each sprint. By holding teams accountable to the goals that they set, it became easy to see when things were and were not working.
    • Experimenting with a four-day workweek to see if we can drive both greater happiness and productivity. This was perhaps the boldest of our experiments; we demonstrated trust in our team and set clear expectations around outcomes rather than hours. This has motivated our team and raised their morale in crucial ways at a time when switching jobs was both tempting and easy.

    Hacks That Worked in Person

    What are some of the things that worked in the office? This list will be different for each organization; for us, it was group brainstorms, in-person one-on-ones, summer Fridays and ongoing vibe checks. Here are some of the ways we hacked these to make them work for remote teams:

    • Group brainstorms: Digital whiteboards like Miro or Mural have been great. Digital sticky notes, too. This has enabled distributed engineering teams to contribute either all at once or asynchronously.
    • Summer Fridays: Give people the afternoon off even if it isn’t technically “leaving the office early.” Or try having everyone shut off notifications on Friday (or Monday morning) so they can get some undisturbed work done before shutting off for the weekend. Monthly mental health days off for the whole company can be a great idea too.
    • In-person one-on-ones: With Zoom, something is definitely lacking. Try spending half the one-on-one meeting chatting casually about things other than work.
    • Vibe check: Open office hours dedicated to work culture; surveys from time to time to gather quick informal feedback or think about other ways to elicit ongoing feedback from every employee, including engineering teams.

    Generate Culture and Well-Being

    What keeps most employees at companies is social bonding, inspiring projects and the possibility for growth. A question a lot of executives at previously onsite organizations are asking themselves is, “How do you fulfill the need for social bonding when most employees, including your engineering team, are remote?” In other words, how do you bond socially and do so remotely? Two goals we have identified are getting team members talking outside of work while avoiding Zoom fatigue issues and ongoing opportunities to share personal successes with colleagues.

    Some of the ways we have built culture are:

    • Having (non-mandatory) Friday lunch and games like trivia, Jeopardy!, games or online games
    • Different ongoing events like photography challenges, health challenges and even an at-home Iron Chef-style cookoffs.
    • Having leaders share how they spent their weekends and time off. We believe in demonstrating a healthy work-life balance from the top down and encouraging our team to take the time they need to unplug and recharge.
    • Figuring out how (and how not) to surface urgent issues via Slack; working on a system to avoid pinging people after hours for non-urgent issues.

    Above All, Manage With Empathy

    These last two years have been exhausting for most people. Hands down, the best way to manage and engage the people you work with—no matter if they are in engineering or marketing—is to be empathetic to the difficulties that they may be going through outside of work. Executive teams can make all the tactical changes to their teams they want, but without managers that really care about their teams, you will inevitably fail to keep the best people around. Empathy-driven leaders lift their team members up and drive the kind of culture people want to be part of.

  • Saying Goodbye to Legacy Systems

    Saying Goodbye to Legacy Systems

    Are you still using a rotary phone, tube television or Rolodex? Probably not. But if you were, you’d still be using newer technology than what many enterprises still rely on every day to drive mission-critical applications that we use every day when shopping, banking or hundreds of other normal tasks. 

    At least two-thirds of large enterprises are running mainframe-based apps that date back 10 to 20 years and more than 25% of businesses feature applications that are between 20 or 30 years old. Today, businesses are often running and maintaining legacy applications built on traditional databases while simultaneously building microservices-based apps to accelerate new services and innovations. The mantra “If it ain’t broke, don’t fix it” certainly applies here; and while there are many reasons organizations continue to rely on mainframes and legacy systems, there are also many organizations that want to begin modernization initiatives but don’t know where to start.

    However, the past few years saw a wave of new digital-first companies in all industries putting pressure on legacy systems-based businesses—from retail to finance to manufacturing to technology. The COVID-19 pandemic accelerated many organizations’ modernization plans and made clear that for those that wanted or needed to modernize to stay competitive, avoiding the problem just wasn’t an option. Companies found that if they weren’t proactive about modernizing, the cost of being reactive when they needed to update and evolve was exorbitant.  

    Accelerating IT modernization initiatives can be a major challenge: Safely modernizing those legacy apps and mainframe systems and the critical data in them can seem impossible, but it can be done. Companies like Kroger, for example, have already made that jump and there’s a lot to learn from them. Here are three things that can help any enterprise on their journey to say goodbye to mainframes and legacy systems:

    You Need a Frictionless Path for Legacy Apps

    Many modern solutions are only focused on greenfield applications and helping newer born-in-the-cloud companies and projects; however, the reality is most Fortune 1000 companies have a lot of existing applications they can’t afford to ignore or completely rebuild all at once. Supporting existing applications with standard interfaces like Postgres while delivering the scalability and resiliency to support modern applications is critical to providing a bridge from where companies have been to where they are trying to go. Distributed SQL databases provide a seamless path forward to modernize existing apps while supporting new and current initiatives. 

    Embrace Automation

    It’s time to stop relying on complex code or fragile systems with bolted-on third-party tools. Being able to rely on intelligence and automation in the data layer for distribution, resiliency and availability is critical to minimizing changes and impacts on current applications. Doing so will reduce risk, offload legacy app tasks and ensure systems have the intelligence to work properly. With a distributed SQL database, you can deliver a single logical database that appears to applications like a monolithic, single-server database but with the underlying intelligence to allow it to stretch across hybrid, private and public clouds. 

    Finding Flexibility and Becoming Future-Proof

    To avoid being tied to specific systems or architectures, it’s time to adopt a future-proof mindset. Businesses can achieve this through:

    • Multi-cloud/hybrid cloud: With a distributed SQL database, you can deliver a single logical database that looks like a monolithic, single-server database but with the intelligence to stretch across hybrid, private and public clouds—providing the flexibility to be deployed wherever the application is needed or is best served.
    • Any hardware: No two data centers look alike and there are a wide variety of hardware needs, from bare metal to VMs and containers. The right modern distributed database provides ultimate flexibility in where the data layer can be installed to match whatever hardware and configurations are already in use. 
    • Any deployment: Existing organizations have a wide variety of environments and deployment types, from single data centers to two or more private data centers to more and more hybrid environments that span on-premises and public clouds. A modern distributed database provides the freedom to support a wide range of deployment options, including synchronous replication, geo-partitioning and cross-cluster asynchronous replication.  
    • Open source freedom: While many databases provide some open source components, there are still a few 100% open source solutions committed to the Apache 2.0 license. Users can benefit from the full set of enterprise features and capabilities in these open source solutions as well as benefit from the security and transparency that comes with a 100%-open source solution. 

    It’s time to update the old adage, “If it ain’t broke, don’t fix it” to “If it ain’t fixed, it could be broke,” with regard to modernizing legacy systems. If you’re considering starting a modernization journey, save time, resources and money now to make upgrades that might later be costly, time-consuming and overwhelming for your internal teams. 

  • Could Buying VMware Bring Broadcom Hybrid Cloud Bona Fides?

    Could Buying VMware Bring Broadcom Hybrid Cloud Bona Fides?

    Rumors are swirling that Broadcom wants to buy its way into the growing hybrid cloud market by acquiring VMware. The deal won’t come cheap—after news of the potential deal surfaced, VMware’s market cap soared to around $50 billion. Yes, billion with a ‘B’.

    As interest rates increase and investors reevaluate many of the lofty software company valuations, I expect to hear many more acquisition rumors. During this time of uncertainty, cash-flush vendors are going to be on the hunt for software vendors that can provide a technology platform, have large partner ecosystems and that also produce reliable revenue.

    Why the Acquisition Makes Sense for Broadcom

    Broadcom has a nice, solid business producing semiconductors for smartphone makers as well as storage and networking devices used in large data centers. However, like many hardware companies, the business has been desperately trying to break into the software industry. Why? There’s a semiconductor shortage and the company is in the right market at the right time. However, the company’s leadership knows that market conditions change. Software margins are significantly higher than hardware deals, and R&D and manufacturing costs for semiconductors are notoriously high.

    VMware has grown to become a large cloud technology platform, not just a virtualization offering. If Broadcom is able to successfully close on this deal, it will instantly own one of the largest cloud software platforms in the industry. In addition to acquiring large enterprise customers, the VMware partner ecosystem is important. For example, I believe that the NVIDIA partnership will be a profitable one for VMware. The two companies have been working together to create a platform to support AI-based applications for the data center, cloud and at the edge.

    In a time when some cloud businesses are experiencing wild fluctuations because of their lack of profitability, the VMware business model is solid. However, these fundamentals are also why the company is ripe for acquisition. In its fiscal year 2022, the company reported $12.85 billion in revenue and $6.33 billion in subscription and SaaS licensing revenue. Free cash flow for fiscal year 2022 was nearly $4 billion.

    Let’s quickly contrast VMware to the cloud data warehouse Snowflake (NYSE: SNOW). Snowflake’s market capitalization is around $40 billion and within the last year was well over $120 billion. Meanwhile, the company’s revenue is around $1.2 billion and it is struggling to find a path to profitability. If you were hunting to acquire a software business during a time when financial indicators are flashing red, which business model would you prefer?

    Broadcom’s Strategy: Become a Software Company

    I mentioned that Broadcom is desperate to gain relevance in the software industry. Why do I say this? The company’s recent acquisitions showed a clear pattern emerging—Broadcom has been trying to acquire its way into software.

    In 2018 the company acquired CA Technologies for nearly $19 billion. The following year, Broadcom acquired Symantec’s enterprise cybersecurity business for $10.7 billion. In addition, there were rumors that Broadcom was planning to acquire SAS Institute, the privately held analytics vendor, for somewhere around $15 billion to $20 billion. Those talks fell through when the SAS Institute’s aging co-founders and majority stakeholders announced a plan to go public in 2024.

    This M&A strategy might seem strange to many, but Broadcom originally tried growing through the acquisition of companies similar to itself. In 2018, the company made an offer of $117 billion to acquire chip producer Qualcomm. Broadcom later withdrew the bid when it became clear that the Trump administration pushed hard to prevent the deal, citing national security concerns.

    Although this latest deal would face governmental review and the Biden administration previously voiced concerns over tech mega-mergers and monopolies, we have not seen the administration prevent similar deals.

    The Path Won’t be Easy: Three Strategies for Success

    The market is full of cautionary tales of software vendors that were acquired only to be slowly destroyed. A successful acquisition would require Broadcom to tread lightly and maintain the elements that have made VMware the company that it is today. Below are three priorities that Broadcom should focus on if the deal is completed.

    Keep VMware independent: It is critical that VMware does not show favoritism toward one chip maker. VMware’s largest customers use chips from Intel as well as other manufacturers. If Broadcom tries to steer VMware toward its own chips exclusively, the backlash could quickly undercut the value of the acquisition. In addition, it’s my belief that the hybrid and multi-cloud models are here to stay (rather than a single cloud approach). Customers expect vendors to work with each other and are reluctant to accept single stack proprietary approaches. 

    Find innovative DNA and facilitate business unit collaboration opportunities: Hock Tan, Broadcom’s CEO, is very well respected in the industry; however, the company is not known for software innovation. Although I expect VMware to remain a standalone business unit (similar to CA’s current position within Broadcom’s ecosystem), it will be important to foster innovation. Broadcom should accelerate VMware investments, like Project Monterey and the NVIDIA partnership, while looking for new investment opportunities. Perhaps Broadcom could provide VMware with custom chips to help accelerate Project Monterey, but this sort of line-of-business collaborative innovation hasn’t been the model for Broadcom’s other software acquisitions. It should be.

    Nurture the partnership network: The next phase for the VMware partner ecosystem will require partners to understand the company’s vision for the future. What will the acquisition mean for partners? Will they have access to more solution selling that combines VMware and Broadcom technologies? How can existing Broadcom partners join the VMware partnership ecosystem? That will be another big question.

    It will be extremely interesting to see how this plays out. We’ll definitely be keeping an eye on this potential merger of two heavyweights!

  • Is Your Future in SaaS? Yes, Except …

    Is Your Future in SaaS? Yes, Except …

    The growth of SaaS—including IaaS—was phenomenal when it came and it has become somewhat pervasive. Today, there are SaaS tools in use at just about every business, large or small. From sales to marketing to customer management, there is a SaaS tool that does it affordably and well. For now. The same is true of cloud vendors. Cloud prices are kept low by two mechanisms—volume and profit. Volume; much like the theory that mass transit is cheaper, by putting many customers on a single server reduces cloud vendors’ operating expenses and thus reduces what the cloud vendor must charge to make a profit.

    But as costs rise and growth slows in the current environment, it is important that your IT department, as a customer, pays attention to the cost/benefit equation of all SaaS offerings. Some will remain beneficial because of the work they offload, even as prices increase for your organization. Others, you’ll see, will quickly outgrow the value they bring as costs rise and there is a third class that just isn’t worth it—maybe it never was and you haven’t bothered to pay attention.

    Look for those items. So that this is less vague, here’s an example: A company I am involved with has been paying for a SaaS service that simply emulates an on-site functionality. The organization could (and previously did) drop a couple of boxes in and achieve largely the same result. Recently, we looked more closely at items like this and found that, in this particular case, (though not in most SaaS cases the org is using) the cost of dropping two boxes in and letting them do the job was cheaper (assuming those boxes were upgraded/replaced every other year) than continuing with the SaaS solution at the current monthly price. So much cheaper, in fact, that a contractor could be hired to deal with any issues that came up with the physical boxes and the only increased work for IT would be maintenance updates to keep the system secure. If, instead of appliances, the solution consisted of two Windows or Linux boxes, even that maintenance cost would be minimized.

    Service will be the same or better—the devices are right there if a change is needed—and there will be one less link in the chain of tools/vendors for attackers (the physical solutions would be on a private subnet, SaaS cannot be). Assuming the solution is a quality product, there really is no downside here. And yet, for several years this company has used the SaaS solution. These are the low-hanging fruit that people will point at and call “retrenchment” or whatever. Ignore them. Do what’s best for your org—be it SaaS or local—and make that decision on a per-tool/per-project basis.

    And keep kicking it. You’re building apps and infrastructure that keep the company running. Don’t hesitate to take pride in what your team(s) have built and don’t hesitate to cut costs on things that don’t matter so you have more funds for things that do. And once again, thank you—from all the employees in your organization that don’t realize they should say thanks.

  • Container Storage for DevOps: New Options With NVMe

    Container Storage for DevOps: New Options With NVMe

    The DevOps world is ripe for a storage paradigm change, both in how it operates within the enterprise and how it implements applications. 

    NVMe, especially NVMe-over-fabrics (NVMeoF), is both a tool and a host target that can provide such a change—especially in the new world of microservices and containerization. NVMe can drastically improve application performance over classic implementations and, given the right tools, transform the process of writing those implementations to be faster, more robust and more flexible. 

    I/O-Intensive Work

    A quick recap shows why this is so. The DevOps build toolchain, especially for large codebases, has always been heavily I/O-dependent and storage access has classically been the biggest bottleneck for building an image. The ability to cluster small, inexpensive Linux x86 servers connected to SANs twenty years ago was a first step in separating storage hardware from compute, but I/O latency was pretty awful. Build/link operations could actually take longer than the compilation of object files. 

    Virtualization helped make hardware utilization better and cheaper but didn’t really improve throughput. Cloud infrastructures such as OpenStack and CloudStack made those infrastructures simpler and more elastic to manage but, again, the IOPs bottleneck remained. 

    Containerization for DevOps made it even simpler from the applications level—just deploy the app and ramp up container instances as needed—no more dedicated infrastructure needed. And it’s cheaper for incremental functions. 

    However, not much was done to clear the I/O bottlenecks for largescale storage and increasing overall performance. 

    When the new nonvolatile memory technology of NVMe came to market in 2014 for the single server world, it delivered two game-changing capabilities. 

    1. An increase of 5x disk access I/O speed. This was, arguably, the biggest single performance improvement since multicore processors with onboard cache (think Opteron) emerged. With Linux adding support for standard, open source NVMe drivers in 2021, the options increased beyond Windows and Mac users.However, SANs and their protocol stack were still an issue. SATA- and SCSI-based SANS performance was gated to the 1.2GB limitations of those technologies and big iron to head-end the SAN still dictated high-cost infrastructure.
    2. Unlike SATA or iSCSI, NVMe has the native capability for TCP/IP or fibre channel addressing. This allows NVMeoF to be an autonomous point for data storage in a normal network. A user can now keep control of their data but use network-attached compute as a utility with roughly 6Gb speed for I/O—greatly lessening the big penalty for disk I/O.  

    Applying Containers

    The dramatic uptick in container deployments and the debut of container attached storage (CAS)—software that includes microservices-based storage controllers that are orchestrated by Kubernetes—represented another industry milestone. These storage controllers can run anywhere that Kubernetes can run, which means any cloud or even bare metal servers or on top of a traditional shared storage system. Critically, the data itself is also accessed via containers as opposed to being stored in an off-platform, shared scale-out storage system. 

    Since container-attached, cloud-native storage enables the use of small, disaggregated architecture without the need for large-scale SANs or storage controllers dovetails nicely with DevOps work. 

    Container-based applications can benefit enormously from NVMe-based storage. As experts have pointed out, since DevOps applications are all about scalability, the parallelism embedded in the NVMe spec fits nicely to support them. 

    While SANs are good for large-scale contiguous operations, they’re expensive chunks of capacity and not nimble to deploy. They’re also bound to the slower I/O storage protocols, which can negate performance gains possible by adding NVMe to that array (as opposed to discretely).

    Container-based storage with NVMe gives DevOps teams the opportunity to add storage at low cost with deterministic management of that stateful storage—in theory, of course. In practice, the temptation to add like infrastructure to current infrastructure is powerful, even with all its limitations.

    To make that theory a reality, a control plane with the fast data plane is necessary—and the market is beginning to address this need.  

    As one example, OpenEBS recently introduced an upgraded engine, MayaStor (now part of DataCore Software), which enables use of NVMeoF at impressive speed: Benchmarks with Intel SPDK architecture show a 5x read/write speed improvement over SATA.

    OpenEBS debuted a few years back as a containerized storage solution for Kubernetes-based applications. With an optimized storage engine, Kubernetes has the opportunity to perform like other, more specialized hosting and development solutions. 

    Impact for DevOps

    What does this mean for DevOps teams? Firstly, using NVMe in containerized DevOps applications speeds up the time required for large builds, thereby speeding iterations of writing software. It also removes the need for complex and expensive SANs to host build environments. This double whammy of benefits means that development is quicker and cheaper and, in turn, applications can deploy faster while using more flexible tools.

    Second, NVMe greatly mitigates I/O concerns for how application code is designed and how environments are implemented. No more being beholden to the storage trunk—NVMeoF drops the performance penalty for I/O ops and distributes traffic across a normal TCP/IP network. This is now a triple whammy—faster, cheaper and more flexible containers built atop a fast, flexible virtualized infrastructure.

    Backed by innovations in container-attached storage, DevOps teams can achieve the agility and flexibility that are paramount to its mission—and act as a proving ground for the rest of the IT team to consider alternative paths to greater efficiency and performance.

    Join us for KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain (and virtual) from May 16-20—the first in-person European event in three years!

  • Pulumi Extends Infrastructure-as-Code Reach

    Pulumi Extends Infrastructure-as-Code Reach

    At its online PulumiUP conference, Pulumi announced it will make its Pulumi CrossCode translation technology available to third parties and DevOps teams. The technology was developed to integrate a wide range of programming languages with its infrastructure-as-code (IaC) platform.

    The company also announced it has added support for YAML—widely used to configure Kubernetes environments—as well as any variant of Java. It already supports .NET, Node.js, Go and Python programming languages.

    Finally, Pulumi also added packages for Oracle Cloud, Databricks and EventStore that simplify deployments on those platforms. The company already provides similar integrations for Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Kubernetes, Auth0, CloudFlare, Confluent Cloud, Datadog, DigitalOcean, Docker, GitHub, Kong, MinIO, MongoDB Atlas, PagerDuty, Snowflake, Spot by NetApp and SumoLogic. There are also now components that provide support for container applications, Kubernetes clusters and serverless applications along with an AWS Cloud Development Kit (CDK).

    Pulumi has been making a case for an IaC approach that enables developers to use programming languages they already know to provision infrastructure as an alternative to having to deploy and master tools such as Terraform.

    The Pulumi CrossCode translation technology the company developed is now being made available to any organization that wants to add support for another programming language. It converts any infrastructure-as-code format, including Terraform, CloudFormation, Azure Resource Manager and Kubernetes configuration, to any programming languages supported by Pulumi.

    Pulumi CEO Joe Duffy said the goal is to extend the overall reach of the translation technology the company created to simplify provisioning any type of infrastructure.

    While many developers use tools such as Terraform, the need to limit misconfigurations is driving many larger enterprises to revisit their approach to IaC to improve software supply chain security, noted Duffy. Today, Pulumi claims more than 2,400 organizations have adopted platforms that enable developers to provision infrastructure and apply guardrail policies to reduce errors. That approach prevents developers from making configuration mistakes that can lead to exfiltration of data via, for example, a port that has been accidentally left open, he added.

    Too many developers assume that their cloud service provider is securing both the underlying platform and how it is configured only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned without some ability to apply policies that enforce rules for provisioning that infrastructure within the context of a larger DevSecOps workflow.

    Ultimately, the goal is to employ automation to resolve these issues once and for all as more organizations adopt DevSecOps best practices. In the meantime, the challenge is doing so in a way the average developer will accept and embrace. Otherwise, they will continue to find ways to work around security teams in the name of productivity, regardless of how insecure the underlying IT environment might become.

  • CloudBolt Adds Modular Automation Framework to Tame Hybrid Clouds

    CloudBolt Adds Modular Automation Framework to Tame Hybrid Clouds

    CloudBolt Software this week added a framework consisting of eight modules that collectively make it simpler to automate, optimize and govern hybrid cloud computing environments.

    Jeff Kukowski, CloudBolt CEO, said the goal is to provide IT teams with a more modular approach to managing multiple clouds that they can employ as they gain additional expertise.

    The modules provided by CloudBolt address everything from providing a repository, dubbed Automation Exchange, through which reusable automation content can be shared to implementing governance policies and tracking cloud spending.

    Other modules address testing and assurance, integration, automated discovery and machine learning algorithms that can be used to automate processes.

    While most organizations employ multiple clouds alongside on-premises IT environments, the management of IT across an extended enterprise is far from unified. A recent survey published by CloudBolt found a full 88% of respondents needed a “manager of managers” that would enable them to unify the various silos that have multiplied across their IT environment. CloudBolt Software is making a case for an IT framework that provides a layer of abstraction through which the management of multiple clouds and on-premises IT environments can be unified.

    It’s not clear whether organizations are deliberately employing multiple clouds or if, because of simple inertia, they have found themselves managing multiple cloud platforms because of decisions made by various application development teams. Some IT organizations employ multiple clouds because they are concerned about either becoming locked in to a specific cloud computing service; others are concerned an outage on one platform might take all their applications offline. Others simply take advantage of services that are better provided by one cloud service provider than another. It’s also not uncommon for one organization to acquire another that relied on a completely different platform to deploy applications.

    Regardless of how IT organizations found themselves managing multiple clouds, the total cost of IT rises as each new platform is added to an IT environment. Just as challenging is the fact that each new platform exposes some type of automation framework. Before too long, IT teams find themselves having to navigate multiple islands of automation implemented across a highly distributed computing environment. In many cases, those automation instances are reinventing the same process that has already been automated on another platform using a completely different toolset.

    It is more a question of time and the degree to which IT organizations will eventually consolidate management of disparate IT environments under some type of unified control plane that enables true hybrid cloud computing. Once that capability is achieved, IT teams should find it simpler to migrate workloads from one platform to another.

    In the meantime, most organizations will be managing multiple IT environments for the foreseeable future. The only thing that is unclear is the volume of workloads that might be running on one of those platforms at any given time. The challenge—and the opportunity—is to regain control over computing environments increasingly more distributed.

  • BMC Integrates DevOps Mainframe Portfolio With Git

    BMC Integrates DevOps Mainframe Portfolio With Git

    BMC has expanded its efforts to bring DevOps best practices to the development of mainframe applications by integrating the BMC Compuware ISPW continuous integration/continuous delivery (CI/CD) platform with Git repositories.

    In addition, the company tightened integration between BMC Compuware ISPW and BMC AMI Ops platform and integrated BMC Compuware Topaz Workbench for building applications with code scanning tools from Vercacode.

    Finally, there is also now a BMC Enterprise Connector for Illumio that provides a bi-directional interface between the zero-trust segmentation platform from Illumio and the mainframe. In addition, the BMC AMI Command Center for Security system can now also surface malicious performance activity to accelerate incident response.

    John McKenny, senior vice president and general manager for intelligent Z optimization and transformation at BMC, said the overall goal is to make the mainframe just another platform where IT teams can apply DevOps best practices to build applications faster. That’s more critical than ever because mainframes are often at the core of digital business transformation initiatives and require integration with a wide range of distributed computing platforms. A recent survey published by BMC found two-thirds of respondents (66%) are investing in new technologies such as AIOps and artificial intelligence/machine learning (AI/ML), DevOps and integrations.

    That approach enables organizations to leverage existing mainframes in a way that minimizes technical debt rather than duplicating functionality, added McKenny.

    When it comes to DevOps in mainframe environments, the biggest challenge these days has more to do with culture than the maturity of the tools being provided, he said. Many of the IT teams building mainframe applications still rely on waterfall processes mainly because of simple inertia and a general fear of change, McKenny noted.

    There is, however, a new generation of IT professionals that have embraced modern development practices across all platforms to accelerate the rate at which applications are built and deployed, said McKenny. That shift is leading to the wider adoption of DevOps best practices within both mainframe and distributed computing environments, he added. In fact, as a result, enterprise IT has never been more hybrid, he noted.

    IBM continues to invest in mainframes, so the platform should remain relevant well through this decade and into the next. Though it’s been nearly 60 years since the venerable platform was introduced, it continues to host mission-critical applications for a broad range of enterprise IT organizations. Most recently, IBM added an IBM z16 edition of the mainframe that adds a dedicated on-chip AI accelerator in addition to quantum-safe cryptography. It’s not clear how quickly organizations that have mainframes will upgrade, but that level of investment suggests IBM is still investing heavily in mainframe research and development.

    Regardless of how—or even who—builds applications for the mainframe, tools such as Git repositories will be more widely used if for no other reason than to more easily share code. Now, the issue is improving the overall level of DevOps maturity within mainframe environments to keep up with the rapid pace at which applications are being built and updated across the rest of the enterprise.