Category: DevOps Practice

  • 8 Essential Generative AI Tools for Building Stand-Out Applications

    8 Essential Generative AI Tools for Building Stand-Out Applications

    Building advanced AI apps demands the right tools. Generative AI is a game-changer with the potential to transform how we craft AI-powered solutions. Whether you’re a pro or new to AI, the right generative AI tools can elevate your projects significantly. In this article, we’ll explore the essential generative AI tools that can help you build remarkable AI applications.

    These tools cover a wide range of functions, from content creation to design and data analysis. By the end of this blog, you’ll have a better understanding of how generative AI tools can elevate your AI projects to new heights.

    GPT-3 by OpenAI

    GPT-3, or Generative Pre-trained Transformer 3, is a remarkable language model designed to create text that closely resembles human writing. Its applications span content generation, language translation and chatbot development.
    ● Pros: GPT-3 is highly adaptable and capable of tackling a wide array of tasks. Its primary strengths lie in its ability to handle complex language-related challenges, making it a versatile tool for developers.
    ● Cons: While GPT-3’s capabilities are impressive, its availability may be limited and using it extensively could entail significant costs. These factors are worth considering for projects with high resource demands.

    Runway ML

    Runway ML is tailored to cater to the creative aspects of AI, offering a suite of tools tailored for artists, designers and developers. It encompasses a wide array of generative models that empower users to generate art, design prototypes and craft interactive experiences.
    ● Pros: Runway ML stands out for its user-friendly interface and real-time creative capabilities. This makes it an excellent choice for individuals venturing into the realm of creative AI projects, providing a smooth learning curve.
    ● Cons: It’s important to note that certain advanced features within Runway ML may be accessible only through a subscription, limiting full access in the free version. This subscription-based model should be considered when assessing its cost-effectiveness for your specific project needs.

    Hugging Face Transformers

    Hugging Face Transformers serves as a repository of pre-trained models specifically designed for natural language processing (NLP) tasks. Its applications are extensive, encompassing tasks such as sentiment analysis, text classification and more.
    ● Pros: Hugging Face Transformers stands out as an open-source platform with a vibrant and engaged community. This ecosystem offers a diverse array of models and tools, making it a valuable resource for developers seeking to harness the power of NLP.
    ● Cons: It’s important to acknowledge that newcomers to Hugging Face Transformers may face challenges when customizing models and engaging in model training. While this platform offers an array of resources, it may require a certain level of familiarity with NLP and machine learning concepts for optimal utilization.

    Midjourney

    Midjourney is a versatile tool designed to tackle creative tasks spanning text, music and image generation.
    ● Pros: Midjourney presents a robust offering of pre-trained datasets and generative models, catering particularly well to creative projects. Its user-friendly interface ensures accessibility for individuals, even those who are new to AI, making it an excellent starting point.
    ● Cons: However, it’s crucial to recognize that while Midjourney excels in the realm of creativity, it may not be the top choice for AI applications that require a strong focus on data-driven tasks. Depending on your project’s needs, this limitation might affect its suitability.

    Synthesia

    Synthesia is a specialized AI tool designed for video generation and customization. Its core function revolves around the conversion of text into AI-generated videos.
    ● Pros: Synthesia streamlines the video production process, delivering substantial advantages for content creators and marketers. Its user-friendly interface simplifies the video creation journey, ensuring that a wide audience, regardless of technical expertise, can harness its potential.
    ● Cons: However, it’s essential to recognize that Synthesia’s primary expertise centers on video generation. This specialization can occasionally limit its adaptability when dealing with a broader spectrum of creative tasks that extend beyond the realm of video production. Depending on your project requirements, this specialization may influence its suitability.

    DeepCode

    DeepCode is a specialized tool dedicated to code analysis and improvement. Its primary mission is to assist developers in identifying and rectifying issues within their codebase.
    ● Pros: DeepCode serves as a highly valuable resource for developers, offering concrete benefits such as the enhancement of code quality and the reduction of errors. It’s thoughtfully designed to streamline the coding process, making it more efficient and effective.
    ● Cons: It’s imperative to recognize that DeepCode’s focus is specifically centered around code analysis. This level of specialization may limit its applicability when addressing AI projects or tasks that fall outside the realm of software development. Depending on your project’s nature, this focus may impact its relevance to non-developer AI initiatives.

    Soundraw

    Soundraw is an AI-powered music generator designed to empower users to craft unique, royalty-free music, perfectly suited to enhance a wide range of projects and content.
    ● Pros: Soundraw’s most significant advantage lies in its ability to generate original compositions, thereby mitigating the risk of copyright issues. It also offers secure and enduring licenses for all creative uses, ensuring that your content remains free from copyright concerns.
    ● Cons: While Soundraw’s AI capabilities are impressive, it may occasionally lack the nuanced depth of creativity found in music created by human composers. The variety of available themes and moods may be somewhat limited, which could affect its suitability for highly specific or unique creative projects.

    VQ-VAE-2

    VQ-VAE-2 is a specialized tool known for its exceptional performance in image compression and generation tasks. It’s the preferred choice when the goal is to create high-quality images while simultaneously reducing data size.
    ● Pros: VQ-VAE-2 stands out as a robust solution for image-related AI applications, delivering substantial benefits in terms of enhanced compression and improved image quality.
    ● Cons: It’s essential to acknowledge that leveraging VQ-VAE-2 effectively may necessitate a solid understanding of image processing and AI concepts. This tool is best suited for users with advanced knowledge in these domains.

    Wrapping Up

    By using generative AI tools in your AI projects, you can open up exciting opportunities and make your work more efficient. But, it’s crucial to think about your project’s unique requirements, check if the tools are accessible, and understand their costs.

    Explore what each tool can and can’t do to decide which one suits your AI project best. With the right generative AI tools, you can bring your projects to life and shine in the world of artificial intelligence-powered applications.

  • Synopsys Report Sees Steady Application Security Gains

    Synopsys Report Sees Steady Application Security Gains

    An analysis of the security automation practices of 130 organizations published today by Synopsys suggests significant progress has been made toward securing software supply chains in the last year. However, much work still remains to be done.

    The annual Building Security In Maturity Model (BSIMM) report found there has been a 22% increase in the number of organizations creating software bills of materials (SBOMs) this year. Additionally, there has been a 10% increase in the number of organizations tracking open source software risks.

    At the same time, there has been a 25% increase in the number of organizations that are fixing all defects found in software and a 15% increase in the number of organizations that can identify potential attackers and track attack patterns.

    The report also sees significant gains in activities related to software development practices (44%), penetration testing (35%) and compliance and policy controls (21%). Usage of application behavior monitoring and diagnostics grew 64% and monitoring automated asset creation grew 45%, respectively.

    The finding and publishing of secure design patterns, the required use of approved security features and frameworks and the use of application containers to support security goals all grew about 25%, according to the report.

    However, the report also noted that usage of possible attack lists dropped by 31%, while expert-driven tasks such as building and applying adversarial security tests declined 25% and use of centralized defect reporting dropped 18%.

    The most widely used processes are implementing security checkpoints and associated governance (91%), creating or interfacing with incident response (90%), identifying privacy obligations (88%), using external penetration testers to find problems (88%), ensuring host and network security basics are in place (87%) and automated code review tools (86%).

    Jamie Boote, associate principal security consultant for the Synopsys Software Integrity Group, said the report suggests more responsibility for cybersecurity is shifting everywhere as organizations rely more on automation to apply security controls. Application development and IT operations are, as a result, able to address vulnerabilities more proactively either before an application is deployed or as soon as a vulnerability is discovered, he noted.

    The challenge organizations will encounter when it comes to automating security processes is there is a tendency to set and forget. Once a process becomes automated, not enough organizations will reevaluate that process as the cybersecurity threat landscape continues to evolve, noted Boote.

    Of course, the rate at which security processes are being automated varies widely from one organization to the next, but the more automated they become, the less dependent organizations become on application developers who typically don’t have a lot cybersecurity expertise. All too often, application developers are rushing to meet software delivery deadlines at the expense of security best practices. Unfortunately, it’s usually only a matter of time before an issue that was avoided is later discovered in a production environment and is considerably more problematic to update, given all the dependencies between software and infrastructure that exist.

    One way or another, however, a pending wave of regulations will soon force organizations to pay more attention to securing software supply chains. The only thing left to determine in the absence of automation is how painful the reengineering of DevOps workflows to embrace DevSecOps best practices is going to be.

  • Navigating the World of Distributed Workforces

    Navigating the World of Distributed Workforces

    The ever-changing software development landscape continues to bring new opportunities and challenges to developers and businesses that hire developers in equal measure. Whether it’s breakthroughs in quantum computing, extended reality development fueling growth in the gaming industry or the deepening complexities engulfing the regulatory landscape, there’s a lot in store for the DevOps community in the coming year. Developers will become increasingly crucial for businesses aiming to future-proof their bottom lines. Tech companies, especially, must grasp the significance of accommodating a distributed workforce to address the diverse needs of a rapidly evolving market.

    Distinct from the conventional understanding of ‘remote’ work, a distributed workforce refers to a deliberately formed team structure that operates from various geographical locations. This model, propelled by technological advancements, is set to evolve significantly, transforming communication and collaboration across distances into a seamless process integral to the developer’s journey.

    What’s Driving the Distributed Workforce Trend?

    There are many reasons behind the popularity of distributed workforces, but some of the main drivers behind 2024’s expected growth include:

    ● Global expansion: As businesses grow globally, having a distributed development team allows organizations to tap into a deep understanding of the essence of a particular language, country or market. This local expertise and cultural awareness contribute to better market penetration and customer satisfaction.
    ● Legal and security considerations: Some industries may have stringent regulations requiring staff and all sorts of contractors and vendors to be of a particular nationality or have a physical presence in specific regions. Compliance with these regulations is easier to achieve by strategically distributing team members across relevant locations and ensuring adherence to legal and security requirements, all while maintaining operational efficiency.
    ● The need for 24×7 operations: By placing team members across different time zones, organizations can ensure continuous coverage throughout the day and round-the-clock productivity.
    ● Cost optimization: By mixing teams from higher and lower-cost regions, businesses can create a cost-effective structure.
    ● Talent availability: The distribution of the workforce is highly influenced by the talent shortage; for example, in the UK. As some geographical locations are known for their expertise in certain industries and technologies, organizations look to these areas for access to a wider pool of skilled professionals.

    Ongoing and Future Challenges

    While more and more organizations recognize the benefits of a distributed workforce, it’s not without its challenges—both for the businesses employing the model and the in-house developers adjusting to it.

    For businesses: These may include having the HR capacity to effectively manage talent recruitment, retention and relationships in the context of near-/offshoring, shortly followed by legal and security concerns. Hiring remote workers while navigating legal frameworks across different locations and ensuring the security of intellectual property and collaboration terms are challenging.

    Additionally, businesses must grapple with extending corporate social responsibility, equality and representativeness initiatives to destinations where local traditions and business environments may not align with standards set in the location of the organization’s headquarters. The traditional ‘offshore’ model—where time zones don’t align—coupled with project fragmentation across various sites, makes asynchronous collaboration, is also a key challenge.

    Retaining talent within distributed teams is another significant hurdle, as methods effective locally may not suffice, requiring new retention strategies. Then, even with these in place, the time required for onboarding becomes crucial for quickly integrating effective replacements or extensions to existing teams. All of this underscores the importance of vendors who possess expertise in managing these aspects within remote teams and are poised to apply and develop these essential skills on a broader scale.

    For in-house developers: When transitioning to a distributed workforce, there may be difficulties in conveying ideas leading to misunderstandings or delays, struggles in adapting to new collaboration tools and technologies such as virtual collaboration platforms or challenges in working collaboratively due to the lack of spontaneous in-person interactions.

    Without effective communication strategies and time given to developers to adapt to new norms, practices and expectations, maintaining team cohesion and engagement can be more demanding in a distributed setup.

    Security concerns also sit with in-house developers as well as business leaders, as they must ensure the security of ideas, code, setup and sensitive information, all while adapting to what may be new security protocols and practices established for the distributed work environment.

    Meeting the Evolving Demands of Distributed Workforces

    Addressing these challenges requires a proactive approach that establishes good communication, collaboration and a supportive remote work culture.

    Alongside using the skills of recruitment vendors, who play a pivotal role in meeting the evolving demands of distributed workforces, employee training and up-skilling is crucial, especially when transitioning from a local to a distributed team within an organization.

    Training programs should focus on clarifying the reasons and goals behind the shift, defining roles and responsibilities post-transition, establishing effective communication protocols and channels and offering recommendations for practices that enhance the overall effectiveness of the new distributed setup. A training approach such as this will ensure that employees not only understand the strategic objectives but also acquire the necessary skills to thrive in a distributed work environment.

    Preparations should also focus on introducing new tools and methodologies for remote work, of which there are already plenty available, with more advanced tech expected in the upcoming year. Examples include:

    ● Employer of Record platforms: Platforms that facilitate compliance with legal requirements are experiencing substantial growth. The future is likely to see these platforms evolving to address not only legal aspects but also HR-related needs, offering more comprehensive solutions for managing distributed workforces.

    ● Remote collaboration tools: While high-speed internet and standard video conferencing tools have become commonplace, the emphasis will shift towards more advanced tools. Virtual windows and other innovative collaboration technologies will play a crucial role in enhancing the remote work experience and fostering better communication and collaboration among distributed teams.

    ● Team performance and delivery measurement practices and tools: As businesses strive for efficiency and effectiveness in managing distributed teams, tools that measure team performance and project delivery will become increasingly important. These tools, integrated into existing project management systems, will provide automated metrics and insights. Some forward-thinking vendors are already leveraging such methodologies to enhance remote team management.

    ● Advanced project and time management tools: Beyond basic project and time management tools, businesses will adopt more sophisticated solutions to streamline workflow, enhance productivity and track progress effectively. Automation in these tools will become essential for managing distributed teams and ensuring seamless collaboration.

    With a host of challenges, tech and demands—all of which are continually evolving—the key takeaway here is preparation. Only well-prepared development teams will be able to navigate the complexities of a distributed work environment successfully and see businesses ready to reap the benefits.

  • Five Great DevOps Job Opportunities

    Five Great DevOps Job Opportunities

    devopsy.kinsta.cloud is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

    Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

    Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

    The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

    We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

    SimplyHired.com

    Selby Jennings
    Chicago, Illinois
    AWS DevOps Architect
    $191,000 to $242,000

    Indeed.com

    Verizon
    Alpharetta, Georgia
    DevOps Architect
    $159,000 to $201,000

    LinkedIn

    JetBlue
    New York, New York
    Senior Principal DevOps Engineer
    $134,600 to $210,100

    Dice

    Northrop Grumman
    Dulles, Virginia
    Senior Principal DevOps Engineer
    $120,900 to $181,300

    CareerBuilder.com

    Octo
    Washington, D.C.
    Platform DevOps Cloud Engineer
    $110,000 to $170,000

  • KubeCon 2023: Developer Productivity and Platform Engineering

    KubeCon 2023: Developer Productivity and Platform Engineering

    Mitch Ashley: Hey everybody. Welcome back to KubeCon here in Chi-Town, Chicago, 2023. I am joined by Venkat Ramakrishnan. Welcome. With Pure Storage, right?

    Venkat Ramakrishnan: Yes.

    Mitch Ashley: Great. And you are in charge of product and engineering?

    Venkat Ramakrishnan: Yes. Yeah.

    Mitch Ashley: Cool. So you want to talk about something I want to talk about, and that’s platform engineering.

    Venkat Ramakrishnan: Yeah.

    Mitch Ashley: We’ve done some work in this area. And in my mind I think the timing for platform engineering is perfect because the focus on developer productivity and reorienting… DevOps is just about everybody else helping developers do their job. It seems like platform engineering has really been good at adapting in ways that organizations need that function in their company.

    Venkat Ramakrishnan: Yeah, absolutely. If you look at most of the modern enterprises, one of the most precious resources they have as a developer, they want to make sure the developer community is thriving, is able to move their products and the experiences forward, and are able to get the most out of the infrastructure without being slowed down by the infrastructure.

    And I always joke around, if data is the new oil, then developers or the new engines of the economy. So you really want… every enterprise out there is a modern software enterprise, a digital enterprise. And without the developers moving the business forward, they’re going to get left behind. So you have to look at it from that perspective as to why platform engineering is so critical in even the post-pandemic age. It has really accelerated it. We were all part of the Kubernetes container community.

    You could see some of the early adopters, innovators trying to drive a platform story, consolidate the services. But as more and more folks were remote, as more of the tasks had to be consolidated, and the more teams had to be consolidated across, we saw over the last couple of years, in the post-COVID era, the platform discipline. The platform engineering discipline has really taken a strong hold and we see a lot of customers run platform engineering orgs that centralizes all of the DevOps capabilities they had distributed before but also brings a lot of control over cost, security, governance, regulatory stuff, and all of that.

    So it gives them a one stop shop for everything that the developers need to build and run their applications. And that’s where Kubernetes really shines. If you really go back and look, the vision for Kubernetes and containers is that you enable developers to build, ship, and run anywhere. But now all the tooling has matured and all the organizations, many of the world’s largest organizations have embraced it. So we see a ton of adoption, a ton of growth there from the perspective of folks running their applications and building these internal developer platforms and everything. Yeah.

    Mitch Ashley: We abstract things, and containers simplify things to make parts of the pipelines more efficient and easier. That complexity goes somewhere else. Maybe it gets replaced by technology, but we still have to engineer the test, development, production environments we’re going to be in. We want those to be the same or as similar as possible. That’s one domain of platform engineering. There’s also developer portals and that kind of thing too.

    Venkat Ramakrishnan: Yeah, yeah.

    Mitch Ashley: Are you focused more on the platform in platform engineering, or do you expand into other parts?

    Venkat Ramakrishnan: No, that’s great. Our mission is to make the platform engineers’ life easy, but definitely our consumers are developers. See, the platform engineering team exists to serve their application teams and to help them build, ship, and run faster. But there are essentially two major personas that we build our products for. One, the top persona for us is a platform engineer, and they’re our superheroes, I call them. I just came off a customer meeting and they just told me they have about 6,500 to 8,000 developers on a platform which is building out about 100,000 builds a day, and their team size is only eight people.

    Mitch Ashley: Wow. That’s impressive.

    Venkat Ramakrishnan: That’s how lopsided the developer-to-platform engineer ratio is. There’s the large development teams, really small platform teams. So what they need is a lot of automation. They need a lot of observability. They need to be able to control or manage the platform through policies, through rules and rule-based automation and all of that. So our job is to provide that to the platform engineering orgs, the platform engineers so they can have a quality of life.

    But at the same time our customer’s customer is also very important to us, and most of the time or almost all the time it’s the developers who are the customers of the platform. They’re application users or the clients of the platform. So we build it so that these application teams have visibility into what happens to the infrastructure. They know how to manage the infrastructure without having to file tickets so they can even make the underlying infrastructure behave the way they want, for example, with respect to performance or how the data is placed, how it is all backed up, how you can do a DR across, or how you even migrate between versions.

    So there are a lot of these things we let our developer community be able to control and manage so they can get the most out of their platform. And we don’t just stop there. We have also let our developers, our platform teams protect the platform like at the data level, at an application level, but we have also surfaced those capabilities to the developers as well. So if you’re a developer using a namespace. You have your applications running in a Kubernetes namespace, you can back it up. Or as a platform admin you can back up the entire Kubernetes cluster and you can also restore just the namespace if you want.

    So we give different fine grain controls for both the users. And not just that. We didn’t stop there. One of the toughest workloads to run, any environment, is a database. And there was a lot of fear, uncertainty, and doubt about, can a database really run in Kubernetes? If you go back to the early days of Kubernetes. Portworx is one of the companies that emphatically said, “You can absolutely run databases on Kubernetes.” And they are actually best suited, especially the modern cloud-native databases, they’re best suited for running in Kubernetes because they need scale, they need agility, they need elasticity. And what better than a Kubernetes infrastructure to give you that?

    Mitch Ashley: Distribution. All kinds of things.

    Venkat Ramakrishnan: Exactly. So we have been shipping Portworx data services, which makes it so easy to automate about to 14 important databases, and we’re continuing to add more and to run these databases anywhere from day zero to day two ops. Install, upgrade patching, all the way to doing DR for databases. You can literally deploy a clustered Postgres in a matter of minutes and you can set a DR policy so if your entire AWS region goes down, you can spin up in another region again in a matter of minutes. In a few minutes RPO.

    Mitch Ashley: Let me ask you, and it may not be a fine line, but where does a platform engineer’s job start and end and a developer’s begin? What is that middle point where they intersect with each other? Because platform engineering isn’t just taking a bunch of stuff from developers and doing it for them. Developers still have to have their own way of… I might want to spin up an environment. “Create this for me. I don’t want to open a ticket.” Like the old days. So what does that middle part look like?

    Venkat Ramakrishnan: Yeah. I think this goes with the principle that if you build it, you own it. That means a platform engineer is not going to do the developer’s job for them, and neither is the developer is going to do the platform engineer’s job for them. Where the line draws is like a platform engineer looks… If you look at the platform engineer’s view of their day-to-day work, they are making sure their environment is up and stable, it’s able to serve up apps, people are able to deploy applications and get them running within the SLA they promised, and they are looking at it, the environment as a whole.

    But a developer’s view is they have a namespace or a few namespaces and a provision for them. They have authentication into that. Their view is very narrow. They’re focusing on their application. They’re focusing on how performing their application is. They’re focusing on the uptime of their application. They’re focusing on how they can do code patch updates and security updates to their application. They are making sure their application runs in compliance with the platform’s requirements. It is secure, it has all the latest CVEs patched, it’s able to get the performance it needs. It’s backed up at their level and all of that.

    So developer’s scope is very narrow to their set of applications, but a platform engineer… a developer doesn’t go tell the platform engineer, “You know what? You need to add more nodes in your Kubernetes platform.”

    Mitch Ashley: They don’t want to have to.

    Venkat Ramakrishnan: That’s the platform engineer’s job. Yeah. They don’t want to have to. They shouldn’t be because it’s invisible to them. So what Kubernetes essentially delivers is an invisible infrastructure to the developers. And for the platform engineer, the platform engineer is not going to go to developer to say, “You know what? You should rewrite your code because this is how this platform works-”

    Mitch Ashley: Won’t go over well if they do.

    Venkat Ramakrishnan: Exactly. And we all know the biggest inertia in enterprise, especially in software enterprises, that no developer wants to rewrite their application because it has to work for a different infrastructure. That’s what a lot of infrastructure companies think. Oh, I have a new API. All the application-writers are going to rewrite this applications to use by new API.

    Mitch Ashley: Good luck.

    Venkat Ramakrishnan: That’s why Posit still survives. We were having a raging debate yesterday in one of our community dinners we had. People were asking, “Why is Posit still around? Why is Block still around?” Because you have billions of apps out there that use these interfaces, and they work. And I guess object is a new interface, and we support it, but hey, I have seen-

    Mitch Ashley: And nobody’s going to pay to move it. Why? What’s the value?

    Venkat Ramakrishnan: So you’re going to see that the platform engineer cannot dictate the application developer to say, “Go change your app.” That’s whole reason I talk about databases. You could offer a bunch of data services, but a developer is going to come in, especially you’re building a new age app, you’re trying to bring in a new digital experience. They’re going to say, “Look, I’m going to use this high-speed database that can really do this many transactions or a few hundred nodes, or a few hundred or billions of users.” And the data service you offer may not be scalable to deliver that.

    That’s why we’ve built these Portworx data services, because we want to offer the most favorite databases for developers and make it easy for them to run so they don’t have to wrangle with platform and the team and all of that on which data services they need to run for them. Because again, platform engineers are not database experts. And DBAs are not platform experts. So we wanted to marry that together and offer this to database teams, application teams, how you can run these modern databases and how you can simplify it. Again, that is the clear separation of responsibility. I hope that answered your question.

    Mitch Ashley: Yeah. No, very good. Tell us a little bit about, what does your product do? What’s your approach to market? How do you help platform engineers do their part of this ecosystem?

    Venkat Ramakrishnan: Yeah. Our product, as I mentioned, we have a complete data platform. It has storage, backup, and data services. We continue to add and expand it so we can engage with our customers in pretty much any stage of the journey. For example, if your customer is starting out early, you have an enterprise customer, you’re running a bunch of workloads, but hey, you’re not ready to run data services. You’re not ready to run mission-critical applications, but you are running a ton of apps in your… so we can start you with data protection, or your Kubernetes data protection, like where you can back up and restore your Kubernetes clusters. You’re always compliant with your security policies. You’re protecting your Kubernetes or the platform operations against ransomware attacks, and all of the great stuff. But we can go from there and then say, “You know what? You could run all of your mission-critical apps, including your complete application stack, your databases, get back-up in DR with our Portworx enterprise data management software.”

    And the third thing is you can add to the platform and run any database of your choice from our catalog, that you can immediately spin it up and get your application teams to use it. Our primary mission is to serve the platform teams, as I mentioned. So we sell primarily to platform teams. If you look at all of our large customers that run thousands of nodes of Portworx installs, they’re all mostly platform teams. But almost always the developers are consuming that platform, the application. So we look at developers as a community of users that actually leverage the service that’s available to them or provided to them. We are the platform team.

    It’s kind of like if you’re in a company, the IT offers you a service and we as the employees of the company use that IT. For example, it could be email, it could be something like Slack. Same thing. A platform team offers a whole bunch of services to a community of developers who are building apps, and that’s what’s driving the business. Yeah. So we sell to the platform teams, but consumed primarily by the application developers.

    Mitch Ashley: Great. And Portworx, is that a SaaS cloud offering, or you on-prem as well?

    Venkat Ramakrishnan: We have on-prem as well as SaaS. Honestly we have seen explosive growth in both the deployments.

    Mitch Ashley: And you really have to be in both to serve the center parts, right?

    Venkat Ramakrishnan: Exactly.

    Mitch Ashley: Very good. Can folks kick the tires like with the cloud service? Or how do folks learn about what you can do with Portworx?

    Venkat Ramakrishnan: Yeah, they can go… for example, we have an Essentials version of Portworx. They can go to central.Portworx.com and download our Essentials version. We have backup as a service. There’s a free tier version of the backup that they can go play with. You can just sign up, self sign up. You don’t need to contact us. You can just come onto a portal, self sign up. Point it to your Kubernetes cluster, your namespace. You can back it up as much as… we have some upper limits, but it’s pretty liberal. Then we have a trial version.

    If they want to play with the enterprise, the entire suite of the platform, then they can download a trial. It’s unlimited from a features standpoint but limited by a certain number of days for you to play with and run. And then feel free to ping us, and we’re happy to always chat. We want to be partnering with our customers’ journey. Our mission is to make the platform engineer’s life easy. To give them the time back. To let them manage complexity at scale, and to be able to deliver these services and keep their SLAs but serve a large developer community. So again, we are on their side. They are our superheroes and we’re there to serve them.

    Mitch Ashley: I’m sure they appreciate the help. Tell us the URL again to go check this out. The web address. Where do they go?

    Venkat Ramakrishnan: Yeah. It’s ww.Portworx.com, ww.Portworx.com. They can go to central.Portworx.com as well to check us out. There’s a ton of help on docs.Portworx.com as well. So there’s a ton of resources. And we have our YouTube channel, which is Portworx. You can subscribe to it. There’s a ton of learning videos. If you go to Portworx.com, there’s also sandbox labs that they can play with as well so they can deploy immediately and run. So there’s a ton of resources to get up to speed. And you can always fight us on slack.Portworx.com as well, and come and ask questions also.

    Mitch Ashley: That’s always great, to get in there, try it, and see what it does. How it works. There’s nothing like hands-on. Well, thank you, Venkat. It’s a very pleasure talking with you. Hope you have a good rest of the show.

    Venkat Ramakrishnan: Yeah.

    Mitch Ashley: And if you’re talking Kubernetes, you’re at the right place.

    Venkat Ramakrishnan: Absolutely. I’m always happy and excited to be here. Thanks for having me.

    Mitch Ashley: You bet.

    Venkat Ramakrishnan: It’s always a pleasure to talk to Techstrong.

    Mitch Ashley: Have you come back again. Always.

    Venkat Ramakrishnan: Absolutely.

    Mitch Ashley: Yeah. It’s an evolving area, right?

    Venkat Ramakrishnan: It is. It is.

    Mitch Ashley: And fast moving, too. So it’s always good to keep up with what’s happening.

    Venkat Ramakrishnan: And this show has gotten so much bigger and so much busier, right? It’s an amazing show.

    Mitch Ashley: It’s pretty amazing. It really is. Well, thanks again.

    Venkat Ramakrishnan: Thank you.

    Mitch Ashley: We’ll be back with other great interviews, just like with Venkat, and talking about who knows what next. We’ll see, but I’ll bet it’s something to do with Kubernetes or cloud or both. So we’ll be talking with you soon. Don’t go away. We’ll be back in a few minutes.

  • Google Taps Nobl9 to Improve Services Reliability

    Google Taps Nobl9 to Improve Services Reliability

    Google announced this week it has added a capability for tracking reliability based on how service level objectives (SLOs) are being met that is based on a platform developed by Nobl9.

    Nobl9 launched a Nobl9 Reliability Center earlier this year that provides a single source of truth about the state of reliability in an application environment. Included in that platform is SLOgpt.ai, a generative artificial intelligence (AI) tool for programmatically creating SLOs and launching natural language queries to determine how well they are being adhered to across a distributed computing environment. The generative AI tool developed by Nobl9 is based on Vertex, a foundational large language model (LLM) provided by Google.

    Kit Merker, chief growth officer for Nobl9, said the generative AI tool also makes managing SLOs more accessible to a wider range of stakeholders.

    The expansion of the alliance with Google is the latest in a series that will make it simpler to manage SLOs across multiple ecosystems, including, most recently, partnerships that have been established with Microsoft and Cisco, noted Merker.

    The Nobl9 Reliability Center is already integrated with more than 50 DevOps, observability and incident management tools. It collects metrics, events, logs, traces and alerts to track incidents, releases, rollbacks, runbooks and other documentation. Those integrations will make it simpler for IT teams to create SLOs using historical data that would otherwise be challenging to define from scratch.

    In time, there is no doubt tools for managing SLOs will become more widely available, but given the dependencies that exist between applications and systems, DevOps teams will need an approach that can be employed across hybrid IT environments, said Merker.

    In general, as more microservices-based distributed applications are built and deployed, it’s becoming more challenging to maintain SLOs across them since they have many more dependencies than legacy monolithic applications. Each feature and application programming interface (API) added over time can adversely impact performance and reliability. The challenge is that it’s not so much that any given service will outright fail as much as it is determining where degradations are occurring that result in SLOs not being met.

    Each IT team needs to provide some sort of objective benchmark that assesses their overall effectiveness at delivering application services by making it simpler to track whether SLOs are achieved and maintained. Not every service needs to necessarily meet a stringent requirement, but IT teams do need to have confidence in the fact that, on average, certain levels of service are being consistently maintained.

    When it comes to SLOs, the challenge is first determining which dependencies might impact the level of reliability that can be maintained in the event of an outage and then, second, making sure whenever necessary workarounds—such as rerouting application programming interface (API) calls to other services—can be easily invoked.

    SLOs, of course, as a concept, have been around for decades, but with the rise of digital services that span multiple organizations, the level of reliability DevOps teams are expected to provide is now being written into business contracts. As a result, the overall level of stress related to managing SLOs is only going to increase in an era where businesses have never been more dependent on software.

  • BMC Adds More Tools to Modernize Mainframe Applications

    BMC Adds More Tools to Modernize Mainframe Applications

    BMC this week added a BMC AMI DevX Code Insights tool that makes use of machine learning algorithms to break apart monolithic COBOL mainframe applications into subprograms that are easier to update and refactor.

    In addition, BMC is now making available BMC AMI zAdviser Enterprise, a commercial instance of a previously announced free tool that uses machine learning algorithms to collect telemetry data from mainframe applications. The commercial version of the tool adds a dashboard built and maintained by BMC that makes it simpler to consume that data.

    John McKenny, senior vice president and general manager of Intelligent Z Optimization and Transformation at BMC, said BMC AMI DevX Code Insights visually maps a mainframe application to analyze data flow and debug applications made up of millions of lines of code in real-time that would otherwise be too complex to unravel. Armed with the insights gained, IT teams can then isolate business logic, refactor subprograms, add application programming interfaces (APIs) or remove dead code as they see fit, he added.

    BMC AMI DevX Code Insights also makes it simpler for organizations to onboard new developers to a project at a time when many of the original developers of COBOL applications are retiring, said McKenny.

    In the coming year, BMC is also committed to adding generative artificial intelligence (AI) tools to its portfolio for reengineering mainframe applications, added McKenny. Those tools, for example, will make it simpler to create documentation for legacy applications, he noted.

    It’s not clear how quickly organizations that have mainframes are looking to re-engineer applications, but as more of them adopt DevOps best practices, they are being updated more frequently. The less monolithic the application, the simpler that task becomes. The issue is that mainframes tend to run large applications that access large amounts of data, so many IT teams are naturally fearful of breaking them if they are reengineered, noted McKenny.

    While there is no doubt that the process of reengineering applications will become more automated in the years ahead, software engineers will still be needed to manage the overall process, said McKenny. The role of the software engineer will undoubtedly evolve, but it’s not likely software development and deployment will be wholly automated any time soon, he noted.

    In the meantime, IT organizations that manage mainframes continue to embrace DevOps best practices to varying degrees. There may be some applications that they continue to build and deploy using waterfall methodologies, but as mainframe applications become integrated into digital business workflows, the need to update them faster becomes more apparent.

    The challenge, as always, is not only providing IT teams with the tools to make that transition but also navigating the cultural issues that inevitably arise any time a change of this magnitude is made to the software development life cycle (SDLC). Regardless of the approach, the building and maintenance of mainframe applications are evolving. The only issue that remains to be resolved is finding ways to reduce the level of friction that transition creates as quickly as possible.

  • CircleCI Extends CI/CD Reach to AI Models

    CircleCI this week revealed it is extending the reach of its continuous integration/continuous delivery (CI/CD) platform to make it simpler to incorporate artificial intelligence (AI) models into DevOps workflows.

    In addition to providing access to the latest generation of graphical processor units (GPUs) from NVIDIA via the Amazon Web Services (AWS) cloud, Circle CI has added inbound webhooks to access AI model curation services from providers such as Hugging Face and integrations with LangSmith, a debugging tool for generative AI applications and the Amazon SageMaker service for building AI applications.

    CircleCI CEO Jim Rose said while there is clearly a lot of enthusiasm for incorporating AI models into applications, the processes being used are still immature, especially in terms of automating workflows that include testing of probabilistic AI models.

    Most AI models are built by small teams of data scientists that create a software artifact that needs to be integrated within a DevOps workflow just like any other artifact, noted Rose. The challenge is that most data science teams have not yet defined a set of workflows for automating the delivery of those artifacts as part of a larger DevOps workflow, he added.

    DevOps teams will also need to make adjustments to a version control-centric approach to managing applications to trigger pipelines to pull AI software artifacts that exist outside of traditional software repositories. For example, the inbound webhooks provided by CircleCI now make it possible to automatically create a pipeline whenever an AI model residing on Hugging Face changes.

    It’s still early days as far as the deployment of AI models in production environments is concerned, but there is no doubt generative AI will have a major impact on how software is developed. AI models are a different class of software artifacts that are retrained instead of being updated, a process that occurs intermittently. As such, DevOps teams need to keep track of each time an AI model is being retrained to ensure applications are updated.

    At the same time, generative AI will also increase the pace at which other software artifacts are being created and deployed. Many of the manual tasks that today slow down the rate at which applications are built and deployed will be eliminated. That doesn’t mean there will be no need for software engineers, but it does mean the role they play in developing and deploying software is about to rapidly evolve. DevOps teams need to evaluate both how generative AI will impact the tasks they manage as well as the way the overall software development life cycle (SDLC) process needs to evolve.

    Each organization, as always, will need to decide for itself how best to achieve those goals depending on the use cases for AI,  but the changes that generative AI will bring about are now all but inevitable. The longer it takes to adjust, the harder it will become to overcome the cultural and technical challenges that will be encountered along the way.