devopsy.kinsta.cloud

Category: Features

  • Perforce Charts Testing Course After BlazeMeter Acquisition

    Perforce Charts Testing Course After BlazeMeter Acquisition

    Perforce Software has acquired BlazeMeter from Broadcom as part of an effort to extend the scope of its testing tools beyond the Perfecto tools for testing mobile and web applications it acquired in 2018.

    Broadcom gained control over BlazeMeter after it acquired CA Technologies in 2018. CA Technologies acquired BlazeMeter in 2016. Terms of the latest acquisition involving BlazeMeter were not disclosed.

    Tim Russell, chief product officer for Perforce, said BlazeMeter adds a complete platform that spans everything from load and performance testing to application programming interface (API) testing. The goal is to enable DevOps teams to push continuous testing further left as part of an effort to accelerate the development and deployment of applications, added Russell.

    The need for continuous testing has become more pronounced as more organizations launch multiple digital business transformation initiatives, noted Russell. The real challenge will be finding ways to embed continuous testing within DevOps processes at a sufficient level of scale, added Russell.

    In fact, the quality of the digital experience those applications provide ultimately determines the degree to which those efforts are likely to succeed, which Russell noted is why so many enterprise IT organizations are reengineering their application testing processes.

    In general, organizations are taking two paths to shift testing further left. Some are giving application performance testing tools to developers to employ during DevOps sprints while others are trying to bring application testers into the application development process earlier. In some cases, organizations are doing both as part of a comprehensive effort to discover issues before applications are deployed in a production environment. Those issue are naturally more expensive to fix after an application has been deployed.

    Perforce, for now, expects to continue to make BlazeMeter and Perfecto available as a set of complementary cloud-based services with some cross-pollination of capabilities occurring over time, said Russell.

    In the longer term, it’s apparent that more artificial intelligence (AI)-based analytics will be embedded within cloud-based platforms that can collect enough data to build meaningful models of development processes. IT teams should also expect to see testing tools make greater use of computer vision algorithms to surface issues.

    One away or another, the entire application testing process is about to become a lot more automated as more organizations are simultaneously building multiple applications. That may not necessarily reduce the need for either a developer or tester to create and manage that process, but it does mean the amount of testing time required for each application should continue to steadily decline in the months and years ahead.

    Hopefully, all that effort will lead to better application experiences being provided to end users more consistently. There is nothing quite as frustrating for any application development team than to discover that 90% of the functionality of an application is not being used because end users are not able to easily surface it. Worse yet, of course, is when an application turns out to be too slow once it is deployed. In either case, it’s difficult to regain that initial end-user enthusiasm for any new application experience after it’s been lost, simply because no one thought through all the use cases that should have been tested much earlier in the application development life cycle.

  • 4 Container Orchestration Security Concerns

    4 Container Orchestration Security Concerns

    Container orchestration is a must-have technical skill, according to 51% of respondents to the 2021 Upskilling survey from DevOps Institute. So, it’s no surprise, then, that container technology is becoming increasingly popular. However, container environments are far more complex and dynamic than other infrastructure, making container security essential. Security ensures containers are running as intended, protecting the infrastructure, software supply chain, runtime and everything in between. 

    If you’re looking to use container-based applications within your software infrastructure, you may want to keep in mind the security risks that come with this technology. To help, I asked DevOps Institute Ambassadors to weigh in on the security concerns they have with container orchestration. Here’s what they shared: 

    Anshul Lalit, head of technology and transformation, Kongsberg Digital

    “One of the most common security concerns with container orchestration is that it shares the host operating system and the host kernel. Thus, it raises the concern that a host OS or kernel vulnerability could potentially be taken advantage of and exploited in a container. An example of this is the recent attacks on Linux’s mmap syscall. Though you can avoid this by using defined best practices, it’s worth noting that any compromise in the host OS could compromise containers in that host. This scenario is in contrast to a virtual machine (VM), in which the guest OS and the host OS and kernel share no common binaries and are thus inherently separated.

    Similarly, a rogue process, a vulnerable container image that is running, and a security vulnerability in the orchestrator can all provide an attacker a means to get their foot in the door. For example, if a container is designed to run with root privileges, an attacker running a vulnerability scanner on the orchestration host will quickly find the vulnerable container.

    Users should follow best practices for securing the containers running in a container orchestration platform by providing a Linux security module, for example, that can enforce a policy that will protect against a rogue container or user from extracting sensitive data from the host system.”

    Supratip Banerjee, solutions architect, Principal Global Services

    “Containers are creating new challenges for cloud security. While these structures are dynamic and automated, new threat vectors are also present for precisely the same reasons containers are useful. DevOps and SecOps teams must be aware and prepared for these possible issues:

    • Containers, unlike virtual machines, share the host operating system on which they execute. If settings are not correctly maintained, the host and containers may be exposed to security concerns.
    • Orchestration automation adds a degree of complexity which can lead to misconfigurations that overprovision access and, as a result, an expanded attack surface.
    • Containers are constructed using pictures kept in public or private repositories; they are frequently reliant on other images, and a single flaw in any of them might spread across thousands of containers.
    • Because containers are ephemeral, IP address-based security measures are ineffective and complicate forensic investigations.”

    Parveen Arora, co-founder and director, VVnT SeQuor

    “If your project(s) involves the use of containers, you will have decomposed your application into its various constituent services, which, while beneficial, isn’t necessarily as secure as if you are using VMs. Since container platforms like Docker borrow code libraries from the host, they’re fundamentally not as secure as VMs. Vulnerabilities in a container environment can therefore allow malicious software to break out of a container and infect the host environment.”

    Vishnu Vasudevan, head of product engineering and development, Opsera

    “The security challenge, especially when it comes to container orchestration, is people think they can spin up their own image or they can download the image from the cloud and start using it. It’s not as easy as everybody thinks. There are vulnerabilities being introduced every minute. You need to have a security tool and processes that can automatically scan for every container that is being splintered. Furthermore, a team needs to create shared practices around blue-green deployments or rollbacks of the container changes that are being pushed into production. 

    From the pandemic alone, we have seen significant cloud movement, but on average, 50 vulnerabilities are introduced every day. In fact, there are people just waiting for loopholes where they can execute malicious scripts. And some people, especially people who are in mining, try to gain visibility into vulnerabilities within cloud accounts and penetrate them to run huge containers for their own cloud mining purposes. On average, it can take 280 days to even detect any vulnerabilities or a hack into the system. 

    Companies using containers must consider threat vulnerability management as part of their orchestration strategy. Do you think the team is experienced enough to scan 50 vulnerabilities a day and fix them? Probably not, since release velocity is shortening a release cycle to one or two weeks for modern application initiatives. This creates a lot of technical debt that can accumulate rapidly, which is why threat vulnerability tactics and processes must be considered when moving to the cloud.”

    Learn more about container orchestration and similar topics by registering for an upcoming SKILup Day. 

  • Welcome to Techstrong Group

    Welcome to Techstrong Group

    Today is a big day in the neighborhood. What neighborhood, you ask? If you are involved in DevOps, cloud-native, cybersecurity or digital transformation, you are in that neighborhood. Today we launch Techstrong Group. Techstrong Group is a combination of all the companies I have been involved in within this neighborhood. It represents the greatest breadth of brands, services, content and tools to help those in our neighborhood. It is the power source for people and technology.

    The combination of MediaOps—the people behind DevOps.com, Security Boulevard, Container Journal, Techstrong TV and more—along with the DevOps Institute, Accelerated Strategies Group and Prospera Events makes Techstrong Group the most comprehensive provider of thought leadership and information to people and companies in our field.

    Techstrong Group also represents the coming together of everything I have worked on over the last eight years. When I launched DevOps.com back in 2013, I knew we were at a pivotal point in technology adoption. The internet had changed the world, but another transformation was coming. This digital transformation didn’t start with the COVID-19 pandemic, but it illuminated the fact that if you weren’t transforming digitally, it would be difficult—if not impossible—to thrive in this new normal.

    This belief that DevOps would be a catalyst in changing the world was shared with me by Jayne Groll, one of my co-founders at DevOps Institute and now my co-founder at Techstrong Group. Over the last six or seven years, Jayne has worked tirelessly to help the “Humans of DevOps” and now will continue that mission as Chief Strategy Officer at Techstrong Group.

    Along the way, I have had a chance to meet and work with some tremendous people. My longtime friend Mitchell Ashley, who was a co-founder at StillSecure with me (along with Rajat Bhargava, who founded StillSecure), founded Accelerated Strategies Group. He is now CTO of Techstrong Group, as well as principal at Techstrong Research, which is where the Accelerated Strategies Group business will operate (more about that in a moment).

    Sean Lowery, another friend who founded and runs Prospera Events, the people behind the InnoTech conferences for more than a dozen years, has also joined Techstrong Group, in our Techstrong Live events business unit. We are excited to have Sean and the whole Prospera team as part of Techstrong Group and officially welcome them to the family.

    I would be remiss if I didn’t mention some other important people in the Techstrong Group team. Parker Yates, our Chief Revenue Officer, has been in this adventure with me since day one. Andre Pino, who joined us from CloudBees, heads up our marketing and operations team as Chief Marketing Officer. He is assisted by Heidi Gilmore who as VP of Marketing has really cranked up our marketing efforts. Charlene O’Hanlon, who started with me at MediaOps more than five years ago as a contract editor, is now Chief Content Officer. Marc Halcrow, who has helped Jayne make DevOps Institute the market leader it is, is now our SVP of Corporate Development and Strategic Partnerships. Finally, our newest executive member, Jason Baum, heads up our Techstrong Association and membership efforts.

    Of course, these are just the executive team members. Techstrong Group is more than 50 people strong with dozens of other contributors. We are grateful for every one of them, who have made what we do possible.

    But none of this would be possible without you. We believe we serve today’s “Masters of the Universe,” the people who are making our digital world possible. The worlds of DevOps, cloud-native, cybersecurity, which are all part of digital transformation, are remaking the world before our eyes. We know you; we believe we know what you want and how we can help.

    It is critical for technology professionals at all levels to understand how technology can improve business processes, revenue, profitability and customer satisfaction. Techstrong Group’s goal is to create a place where technology leaders and practitioners gather to exchange ideas and continually learn, grow and succeed.

    To help with this mission, we have organized into several distinct business units:

    •     Techstrong Media: The business unit with most of the existing MediaOps brands—DevOps.com, Container Journal, Security Boulevard and Techstrong TV.
    •     Techstrong Associations: The business unit comprised of DevOps Institute and the Humans of DevOps association.
    •     Techstrong Research: Our analyst and research business, which includes Accelerated Strategies Group.
    •     Techstrong Live: Our events-focused business unit, which produces both in-person and virtual events.
    •     Techstrong Education: You will be hearing more about Techstrong Education in the coming weeks and months.

    Over the coming weeks and months, you will see more of the full Techstrong Group vision roll out. I hope you find it compelling and will entrust us with the greatest gift you can give: your time. We value you and your time; we know our mission and will continue to try and make sure we live up to our tagline, “The power source for people and technology.”

    So, welcome to Techstrong Group. We don’t view today as the culmination of our story; rather, it is the end of our prologue. Now the true adventure begins. Strap in: The world is an exciting place right now and we want to help you get the most out of it.

  • But What About When You Fail?

    But What About When You Fail?

    One thing Agile and DevOps definitely brought IT was a more accepting view of the whole “mistakes happen” mantra. Crashing systems is no longer a guarantee of a free ticket out the door. Indeed, off the top of my head, I can think of at least two cases where a CIO themselves checked in sloppy code and it trashed the system—CIOs at orgs big enough that they probably should not have been coding in the first place.

    And that brings us to today’s blog. The standard response to “But what if there is a bad update?” is “We’ll just roll out a new version!” That works in some instances. In a lot of instances—most that involve GitOps as part of DevOps—it doesn’t. Implosions can be huge and take out chunks of infrastructure. So you need a better plan than just assuming you can fix it with a forward update. Do you have rollback capability? Are you making use of it, assuring all is set to roll back if needed? Testing to make sure rollback works with the other changes made across the system in this update?

    That is part of the problem. Fixing with a new update is the best option, simply because in the age of massively distributed, microservices-based solutions, rolling back comes with a ton of baggage—enough that it may not be viable for you. Okay. So you can’t quickly roll forward. You can’t quickly roll back. Quick! What do you do?!

    And I don’t have the answer to that question, because I’m not in your organization working on your systems. At some point, all IT is personal. And this is one of those points. You need to know what your best options are if an update spirals everything, and you need to have a plan to implement it. But what your best options are is not going to be the same as the next org. This is that point.

    One option is to keep the ability to build the entire system. That’s a large setup, but every minute systems are down is hurting the company. And that’s what you need to plan for. Think of it as disaster planning for DevOps. A man-made disaster that destroys systems and infrastructure.

    So, like any other disaster planning scenario, walk through the chain that makes the system work, identify weaknesses and list ways to address them. Then test those to make certain they do what you hope they will. Then, set up an automated system to keep this whole plan up-to-date.

    In short, we’re in a new automated landscape, and we need a new automated tool to pull our rears out of the fire when the inevitable happens. Be it from dev error or malicious attacker, it is a safe bet that, sooner or later, you will have a massive systems outage that your DevOps toolchain can’t adequately address. Know what you are going to do. Or at least have thought about it, so you’re not just starting to think it through while coworkers and customers can’t access systems.

    And keep rocking it. This is just another layer of protection for all the hard work you’re doing. Take the extra step. Like insurance, if you ever need it, you will absolutely be glad you did.

  • Global Next-Generation Software Engineering Conference

    Global Next-Generation Software Engineering Conference

    GNGSEC sounds the clarion call for software engineering change!

    The pandemic made 2020 the year where we see some of this decade’s most exciting digital technologies become commercially viable, and others finally go mainstream. Software is the core of digital transformation. In the digital era, the methods by which we produce software also need to be digitized. In the software engineering field, the adoption of AI, big data, cloud computing and cloud-native are accelerating the digitization for businesses.

    Global Next Generation Software Engineering Conference (GNSEC) focuses on a full range of software engineering technologies and is committed to defining the standard of the next generation of software engineering. The event will gather 1000+ Attendees and it will be live with virtual experience where senior software engineers, architects, and team leads connect, learn, and grow. Experts and developers from various backgrounds will be sharing their cutting-edge technical practical experience and cases.

    The majority of the attendees of this event will be from the Southeast Asia region (Singapore, Thailand, Indonesia, Philippines, Malaysia, Vietnam), India and China. Due to the current travel restriction, GNSEC 2021 will be virtually presented via Airmeet. It will offer attendees with virtual exhibitions, virtual conference, peer networking session, business matching session, virtual discussion group.

    Global Next Generation Software Engineering Conference (GNSEC) is co-presented by DAOPS Foundation and Escom Events. The event is part of digital innovation series events that features AI, DevOps, Cybersecurity and digital transformation. Previously the event was presented in Shanghai, Shenzhen, Beijing, California and Hong Kong.

    There will be more than 30 speakers from DBS Bank, ING, IBM, Daimler, Tencent, JD.COM, DevOps Institute, Gitlab, New Relic, SUSE and more to share ideas, experiences and case studies in software engineering.

    Register here to join​​ the event with us to rebuild software engineering.

  • ReleaseIQ Adds Orchestration Tool for Multiple Instances of Jenkins

    ReleaseIQ Adds Orchestration Tool for Multiple Instances of Jenkins

    ReleaseIQ has launched an orchestration framework for the open source continuous integration/continuous delivery (CI/CD) environment that makes it possible for DevOps teams to orchestrate pipelines across multiple instances of Jenkins.

    Seetharam Param, ReleaseIQ CEO, said ReleaseIQ Essentials for Jenkins is an implementation of an existing orchestration platform that enables DevOps teams to orchestrate pipelines across heterogeneous CI/CD platforms.

    The challenge is that organizations that have standardized on Jenkins typically have multiple instances being used by not only different IT operations teams but also owners of, for example, ancillary quality assurance processes. ReleaseIQ Essentials for Jenkins provides an alternative approach to the orchestration tools that CloudBees, the original developer for Jenkins, provides, said Param.

    Jenkins today is being advanced independently of CloudBees as an open source project managed by the Continuous Delivery (CD) Foundation, which is an arm of the Linux Foundation. Founding members of the CD Foundation include CloudBees along with Alauda, Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

    ReleaseIQ Essentials for Jenkins optimizes execution of jobs and pipelines and also provides DevOps teams with a no-code graphical interface to build pipelines.

    DevOps teams can also import and execute Jenkins pipelines and jobs in addition to being able to pre-merge pipelines.
    Finally, DevOps teams are provided insights based on key metrics the platform automatically tracks on their behalf. Those metrics make it possible to quickly discover and fix pipeline issues across multiple Jenkins instances via console log aggregation, noted Param.

    It’s not clear to what degree DevOps teams that have standardized on Jenkins might swap out one orchestration tool for another. However, Param said more organizations are either wary of becoming locked into a specific CI/CD platform or now find themselves in a position where they need to continue employing multiple CI/CD platforms from different vendors. The ReleaseIQ platform provides a means for orchestrating pipelines regardless of how many different CI/CD platforms are employed, noted Param.

    It’s clear the need to embrace orchestration tools is becoming more pronounced. DevOps teams are spending too much time manually maintaining DevOps pipelines. The need for tools to automate the management of DevOps workflows is becoming critical as the number of application development projects that are simultaneously being launched continues to grow. Arguably one of the reasons that DevOps processes are not as widely embraced as they might be is the level of expertise required today to manage all the pipelines that make up a workflow.

    Of course, the level of DevOps maturity varies greatly by organization. It’s not uncommon for even different teams within the same organizations to have significantly different levels of proficiency. The challenge and the opportunity now is to provide those DevOps teams with tools that operate at a high enough level of abstraction to make DevOps accessible to every IT professional regardless of the level of programming expertise they may or may not have.

  • The Role of APIs in Mainframe Modernization

    The Role of APIs in Mainframe Modernization

    Mainframes are historically clunky systems. They are incredibly secure and can process impressive calculations, yet they are complex to manage and challenging to extract data from. This reality is at odds with modern cloud-native infrastructure, which emphasizes distributed computing and portable microservices. So, how can existing mainframes adapt to this connected, data-driven economy?

    I recently met with Dr. Alex Heublein, president at Adaptigent, to talk about the state of legacy modernization. According to Heublein, many mainframes are here to stay for the foreseeable future. However, enterprises are continuing to get value from these systems by adding an integration layer on top of them. By using a REST API layer on top of a mainframe, enterprises could finally open up these systems. This could facilitate bidirectional communication with newer cloud-native services, enable phase migration and edge closer to real-time processing.

    State of Mainframe Modernization

    The software industry changes every day. “Nothing in the tech field is permanent,” said Heublein, yet some legacy technologies will persist into the foreseeable future. In terms of mainframe adoption, Heublein sees a couple of categories of users. First are the large financial services organizations, such as large banks and insurance companies, which are considerably invested in their mainframe architectures and which will likely continue to rely on mainframe environments for their policy management and core infrastructure. “I think there’s a lot of good reasons for that,” explained Heublein. “If you want to process billions of transactions a day, [mainframe] is still a good option.”

    That said, regulations and market pressures are influencing a global movement toward open banking. For example, PSD2 mandates open banking in Europe and industry consortiums like Financial Data Exchange (FDX) are directing it in the U.S. market. These initiatives are encouraging financial services to transform their legacy environments and spurring cloud migration, especially for applications that aren’t mission-critical.

    Heublein pointed out a few different patterns in enterprise mainframe modernization. One approach is that enterprises are rewriting or re-architecting old COBOL applications and keeping them on-premises. Or they are porting and re-platforming the application; moving a COBOL app to a Windows or Linux system, for example. Finally, some are shifting straight to the cloud. For solutions that don’t need to be on the mainframe, enterprises may shift toward cloud-native to free up capacity.

    APIs Enable Legacy Modernization

    Distributed cloud technology is helping businesses scale to the right level. Yet, it’s difficult to jump off the mainframe entirely, noted Heublein. “Very rarely can you take all your stuff and move it all at once,” he said. “It’s a tough pill to swallow.” It’s especially difficult to move core banking infrastructure to a distributed environment—an instant shift could introduce security risks. For this reason, he recommended a ‘phase migration’ approach in which individual components are slowly migrated. For example, an insurance provider may shift their claims engine, policy engine and ratings engine to the cloud one at a time.

    As a result of phase migration, however, engineers must simultaneously support both on-premises and cloud-based applications. They must also ensure bidirectional communication so that these systems can exchange data. This is where a REST API transactional layer is necessary, Heublein explained. Such a layer could enable bidirectional communication between the mainframe and cloud-native applications, abstracting complexity when calling out to the modern world, or intercepting cloud data and filtering it into a format mainframe technologies can process.

    To increase developer usability, abstracting complexity from the mainframe integration process will be the key to building out connectivity. This could involve a codeless development approach with a COBOL sub-routine to call external systems, Heublein said. Automatic restructuring of data will be necessary to enable fluent bidirectional communication, too.

    Four Business Drivers of Mainframe Integration

    So what is the end result of putting an integration layer on top of mainframe systems? According to Heublein, there are four key business benefits of using such an abstraction layer:

    1. Orchestration: Software ecosystems often need to make multiple calls to different applications to collect and transform data. Yet, mainframe environments are very complex and challenging to integrate with. More usable integration fabric for mainframe systems could enable better orchestration of workflows in a developer-friendly manner. By using a REST interface, all apps could be calling the same interface, thus greatly simplifying orchestration between disparate services.
    2. Sustained Adaptability: The world is rapidly accelerating, and enterprises need to maintain and modify these APIs very quickly. Organizations require “sustained adaptability” to adapt and survive in the digital world, said Heublein. Mainframe systems, however, were not designed for the 21st century. Thus, low-code integration layers are critical to empowering rapid development.
    3. Data Transformation: Data is powerful for the business. Data is not only a commodity in and of itself but also is required for AI and machine learning. However, mainframes have a completely different way of encoding data. Thus, there is a need to transform this data into a modern format that businesses can consume. An integration layer between these systems can deliver an improved data consumption model.
    4. Real-Time Processing: You may think online payments happen in real-time; however, payment apps like Venmo are really just an abstraction layer over bank transactions, which may clear as little as twice a day. In short, mainframes are not great at real-time processing. However, more usable integrations to this infrastructure could enable user-facing applications to interact more closely to real-time.

    Another concern is security. Opening up mainframe environments that house core financial infrastructure must be done with extreme care—especially as API attacks remain the number-one rising threat in the software landscape. All organizations building out new integrations will require a secure layer from an outbound standpoint. Heublein said this often involves placing an API management layer or gateway in front of the integration layer. This system enables authorization and functions like a firewall between the internal and external world. It can also enable logging and prevent denial of service attacks, he explained.

    Improving Agility for Legacy Systems

    Legacy systems are entrenched in older technology and carry lots of technical debt, forcing operations to move at a slower pace. Maintainers are also culturally a bit different than the newer breed of cloud-native engineers. “Mainframe people are not … fast,” said Heublein.

    DevOps folks want to build, test and promote projects to production very quickly and, arguably, this agility is necessary to satisfy rising digital innovation demands. Improving integration capabilities for on-premises systems could enable businesses to better utilize preexisting investments while also improving agility.

    Low-code/no-code capabilities could also increase collaboration potential, Heublein added, which could bridge the gap between on-premises engineers and fast-moving business folks. When adopting low-code/no-code tools for mainframe integration, he cautioned against general-purpose citizen developer frameworks. Whereas universal integration layers can work well for many situations, he stressed that a very specific boundary box is best for building APIs for mission-critical applications.

    How is your organization approaching modernization for legacy systems? Let us know in the comments below!

  • Perforce Melds Artifact Package Manager with Version Control Platform

    Perforce Melds Artifact Package Manager with Version Control Platform

    Perforce Software has added a universal package manager, dubbed Helix Artifacts, to its portfolio that enables users of its Helix Core version control platform to store and track source code.

    Gerhard Krüger, product manager for Helix Core digital asset management at Perforce Software, said the goal is to enable DevOps teams that employ Helix Core to access a package manager without having to exit Helix Core.

    That approach also provides a more secure and cost-effective way to store, consume and distribute artifacts that also serves to improve developer productivity, he added. The ability to manage artifacts on top of a version control platform also means DevOps teams will not need to set up additional storage infrastructure or configure separate security permissions just to distribute software packages, noted Krüger.

    Perforce

    Helix Artifacts is a self-hosted package manager that functions as a translator for packages such as NuGet, Maven or Docker that enables them to communicate directly with Helix Core as well as build systems and integrated developer environments (IDEs). Helix Artifacts is made available via a per-server subscription model that costs substantially less than rival approaches to managing artifacts, Perforce Software claims.

    Most DevOps teams are trying to strike a balance between employing best-of-breed tools to build applications and the need to reduce complexity and, ultimately, cost. As such, any time a tool becomes a feature of another platform that a DevOps team uses, there will be a review of the processes being employed. Many DevOps teams are trying to reduce the amount of time they spent maintaining tool integrations.

    There’s also now a lot more focus on software supply chain security. Each new tool generally creates yet another set of credentials that need to be protected as cybercriminals continue to aggressively attempt to inset malware into applications before they are deployed in a production environment. It’s not clear to what degree DevOps teams are looking to consolidate toolchains, but given those rising security concerns, it’s only a matter of time before security teams start to ask why the DevOps toolchain attack surface is so wide.

    In the meantime, the number of organizations that have widely embraced DevOps best practices across the enterprise continues to steadily grow. Over the past decade, most organizations have had at least one application development team embrace DevOps. However, as the pressure to build software to drive digital business transformation initiatives has steadily increased since the onslaught of the COVID-19 pandemic, the need to apply DevOps best practices to accelerate application development has become more pronounced. As a result, more organizations than ever are looking to standardize their application development efforts on a smaller number of platforms to reduce friction.

    It’s too early to say whether the rate at which applications are being developed and deployed since the start of the pandemic has actually increased. The one thing that is certain, however, is the bulk of organizations are now trying to accelerate like never before.

  • 4 Tips To Plug The Cloud IT Skills Gap

    4 Tips To Plug The Cloud IT Skills Gap

    Technical talent is few and far between. The programming world faces a developer shortage, and with this shortage comes a lack of cloud know-how. By now, most organizations have become multi-cloud, yet 86% of IT professionals believe a lack of these skills will slow down cloud projects.

    As more teams transition from older architectures to cloud environments, the IT skills gap could pose a severe bottleneck to software development and deployment. Cloud servers require ongoing maintenance, and managing security and compliance is challenging, even for seasoned developers. Furthermore, it’s easy to overspend in the cloud—without keen insight into vendor nuances, it becomes challenging to select the most cost-effective package for the application at hand.

    I recently talked with Joe Spurrier, chief technology officer and co-founder, cloudtamer.io, to see how teams can improve their cloud strategies while navigating a short supply of IT cloud know-how. According to Spurrier, increasing automation, sharing reusable templates, centralizing best practices and maintaining agnosticism are strategies to amplify cloud results. Below, we’ll expand on these areas to see how they maximize cloud benefits while retaining a lean engineering footprint.

    Automation, Automation, Automation

    “Automation is key to furthering your adoption and use of the cloud,” said Spurrier. The drive to automate comes as no surprise to many DevOps and SRE professionals whose goal is to automate their job away. When automating the cloud, infrastructure-as-code (IaC) is a fundamental necessity. “If you’re getting into cloud, you should probably have some scripting skills,” said Spurrier.

    Automation can significantly aid scalability when setting up additional accounts since engineers must replicate similar operations, such as server provisioning, deployment patterns, monitoring and so on. Automation is also essential for shift-left testing and to increase observability into production environments. “It’s one thing to deploy an application via automation, but another to have tests in automation—that’s the next level,” said Spurrier.

    Now that so many tools are API-driven, orchestration becomes programmable. A cloud service provider’s CLIs or SDKs could also be leveraged to hook into these integrations to construct such automation.

    On the flip side, too much automation for high-level privileges could backfire. “Someone could break into a data center, steal a server, disconnect it, then run off,” Spurrier explained. Thus, automation will require a higher sense of security to ensure that every change is appropriately authorized and logged.

    Reusable Templating

    Along with automation, documenting operational processes to be shared amongst engineering teams is vital for maximizing efficiency in a lean talent landscape. The key here is to make the process self-documenting and reusable, stresses Spurrier. This will most likely involve someone on the team creating shared libraries and repositories for other team members to leverage.

    One such example is Amazon’s golden AMI pipeline. Golden AMIs are virtual machines that teams can “standardize through configuration, consistent security patching and hardening.” Golden AMIs can also enable a repeatable process for performing monitoring, logging and even distribution to business units.

    Reusable patterns are important for building CI/CD systems so that when you commit code, it is automatically deployed to preferred cloud providers. In general, Spurrier recommends building shared repositories that are easy to clone, with step-by-step instructions for usage. Sample applications that demonstrate components in different languages can also aid developer usability and save time.

    Adopt Centers of Cloud Excellence

    Another way to encourage better adoption is by creating a center of cloud excellence (CoCE). For an enterprise, having a cloud-centric project management group can be very helpful to organize knowledge and offer support. A CoCE could centralize operations, supply engineers with pre-configured containers and help distribute access to cloud accounts.

    A CoCE is a good way to start to unite disparate teams around shared best practices, said Spurrier. Depending on your organization’s needs and workloads, a CoCE will focus on varying skills, he added. In the beginning, a company may have just one center for cloud knowledge. However, as adoption grows, dedicated centers may likely emerge around specific cloud providers, too.

    Retain Agnosticism

    Contrary to popular belief, multi-cloud steups aren’t always about lift and shift. Business units often adopt a particular cloud to suit specific workload requirements. For example, researchers may choose GCP for its data science functions, or Microsoft shops may prefer Azure.

    In a multi-cloud world, management layers could help retain a modicum of vendor neutrality. For example, take Cloud Custodian, a tool developed at Capitol One and recently contributed to the CNCF. Using Cloud Custodian, engineers can run security checks across AWS, Azure and GCP and generate metrics for reporting. Such control and insights could empower teams to automate some of the multi-cloud management burdens.

    When working with multi-cloud, it’s also good to consider agnostic tooling that can work across different providers, like Terraform or Kubernetes, Spurrier said.

    Templating

    Cloud transformation is ongoing at most organizations. With this rise, more cloud-native processes and tools are emerging. Yet, with talent in short supply, DevOps isn’t always fully prepared. To review, we covered four ways businesses can circumnavigate this issue to get an edge:

    • Increased cloud automation is a necessary response to a slimmer labor pool. Though building automation requires upfront technical skill, it pays dividends in increased efficiencies.
    • Reusable libraries and templates can rapidly configure new projects and do so consistently across business units.
    • Consider maintaining a center of cloud excellence to centralize policies and offer support.
    • Opt for agnostic tools. This helps to retain vendor neutrality and apply consistent controls across clouds.

    Of these above strategies, Spurrier emphasized the importance of creating shared templates. When used right, a templating approach can be very effective, he says. “If you have a templating model, it should be easy for DevOps teams to migrate to new features. If you’re leveraging tools that set up templates, it’s easier to figure out how much infrastructure is going to cost.”

  • Sumo Logic Extends Observability Scope and Reach

    Sumo Logic Extends Observability Scope and Reach

    During the online Illuminate user conference, Sumo Logic revealed how it is integrating capabilities it gained with the June 2021 acquisition of Sensu, a provider of open source monitoring tools, with its continuous intelligence platform in addition to adding support for data collected via open source OpenTelemetry software.

    Sensu Go, a set of tools for implementing monitoring-as-code, is now a core part of the Continuous Intelligence Platform. The company is also now making available in beta Sumo Logic OpenTelemetry Distro and Ecosystem Support, a single agent through which all logs, metrics and traces can be collected from instrumented applications. Sumo Logic is also supports the AWS OpenTelemetry Distro, an offering from AWS that provides similar capabilities. Sumo Logic has also increased the capabilities of Sumo Logic Free to include monitoring-as-code tools created Sensu.

    Bruno Kurtic, vice president of product and strategy, said as responsibility for managing applications shifts left toward developers it’s critical to provide observability capabilities that can be programmatically infused into applications. As part of that effort, Sumo Logic is now also offering Sensu Plus, which provides access to an analytics engine for the data the platform collects.

    Sumo Logic is also adding machine learning algorithms to provide more context to the alerts the platform generated via an Alert Response feature that is part of the core platform.

    The company is also adding support for the operator software that Red Hat created to make it simple to deploy Sumo Logic Continuous Intelligence Platform alongside the Red Hat OpenShift platform for building and deploying applications on top of Kubernetes clusters. In addition, Sumo Logic is also providing integration with a total of 38 either new or updated observability applications that integrate with a wide range of third-party platforms.

    Finally, Sumo Logic is extending the security observability platform it provides based on its platform to add support for containers and serverless computing functions alongside virtual machines and integrations with third-party endpoint detection and response (EDR), network detection and response (NDR), threat intelligence and managed detection and response (MDR) platforms. The company has also added or updated 26 applications for specific third-party platforms.

    Kurtic said Sumo Logic makes it possible for developers and IT operations teams alike to observe an IT environment on an end-to-end basis via a single pane of glass. In some cases, the members of an IT operations team will require a user interface to manage that environment. Developers, meanwhile, might prefer an application programming interface (API) through which observability data is made accessible from within a continuous integration/continuous delivery (CI/CD) platform.

    Regardless of the type of user, however, IT teams should not have to hire their own data science team to analyze observability data. Instead, the observability platform should embed machine learning algorithms that surface all the benefits of data science without the need to hire additional headcount, he said.

    One way or another, DevOps teams will soon routinely benefit from the additional levels of context that observability platforms provide. The challenge will then be determining how best to fix a raft of issues that many DevOps teams today simply didn’t know existed.