devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • CloudBees Unfurls Dual CI/CD Strategy at DevOps World Event

    CloudBees Unfurls Dual CI/CD Strategy at DevOps World Event

    During a DevOps World event, CloudBees took the wraps off the first major update to the open source Jenkins continuous integration/continuous delivery (CI/CD) platform made in the past several years.

    At the same time, the company also unveiled a proprietary DevSecOps platform based on Kubernetes that is optimized for building and deploying cloud-native applications based on portable Tekton pipelines.

    Shawn Ahmed, chief product officer for CloudBees, said the updates to Jenkins make it possible to horizontally scale Jenkins controllers while at the same time ensuring high availability. The latest update also provides a workspace caching mechanism to simplify sharing them across multiple jobs in a way that significantly reduces the amount of compute and storage resources consumed, he added.

    CloudBees also added a Baseline capability to the Jenkins repository to improve startup times without causing build storms.
    Collectively, those capabilities will increase the number of jobs that can be simultaneously executed to improve overall productivity, said Ahmed.

    CloudBees has also added a Pipeline Explorer tool in the cloud-based edition of Jenkins that enables DevOps teams to visually debug and troubleshoot pipeline jobs. That tool will also provide the foundations for self-healing and artificial intelligence (AI) capabilities that CloudBees plans to add to the Jenkins platform later this year and into 2024, added Ahmed. For example, AI tools will surface suggestions on how to fix a problem in a pipeline, he noted.

    The DevSecOps platform, meanwhile, leverages Tekton pipelines to provide DevOps teams with more granular control over how pipelines can be orchestrated, said Ahmed. It also provides access to GitHub Actions-style domain-specific language (DSL), support for feature flagging, security, compliance, pipeline orchestration capabilities, analytics and value stream management (VSM) tools that can be deployed by an internal IT team or accessed via a single or multi-tenant managed cloud service.

    Those built-in capabilities will make it simpler for platform engineering teams to centrally manage building and deployment of cloud-native applications by enabling developers to self-service their own engineering requirements via an internal developer platform (IDP), said Ahmed. The overall goal is to provide a more integrated approach that breaks down software engineering silos that exist in many existing DevOps workflows, said Ahmed.

    Each DevOps team will need to decide for themselves to what degree to move forward using Jenkins to build and deploy applications versus opting for a more modern alternative in the form of the DevSecOps platform. CloudBees, however, is committed to providing plug-ins and integrations across both platforms to enable DevOps teams to protect their investment in existing tooling, noted Ahmed.

    The status of Jenkins X, an open source CI/CD platform based on Kubernetes that CloudBees previously donated to the Cloud Delivery Foundation (CDF), is not immediately clear. Regardless of the approach, however, there is a clear opportunity to revamp DevOps workflows by upgrading Jenkins or switching to a more modern platform such as DevSecOps. The challenge, as always, is determining the pace at which any such transition might be made.

  • Will ChatGPT Replace Human Software Developers? Probably Not

    Will ChatGPT Replace Human Software Developers? Probably Not

    Since the release of ChatGPT, there has been a great deal of hype around generative AI and how companies can leverage it to cut costs and democratize software and application development. Naturally, with discussions of cost-cutting and democratization come whispers about what will happen to software developers.

    This is a real and valid concern, but software developers’ skills, expertise and creativity are still very much needed.

    While generative AI and AI code generation tools like ChatGPT have shown some promise and potential benefits, they are still in their infancy—like many other innovative technological advancements. We also don’t know what scenarios they may present down the road or their true abilities when the technology matures. For instance, how will it integrate with other technologies? We don’t know what will happen when a ChatGPT-generated line of code breaks or needs to be changed. We don’t know if it can provide a novel solution to a unique problem or what security threats it will present.

    Given these unknowns, technology executives should think twice about replacing experienced and creative technology talent, such as software developers, with AI code generators.

    Will ChatGPT create novel code to solve a unique problem never encountered before? Probably not.

    A Tale as Old as Time (Or at Least a Decade)

    The technology industry has been searching for and developing new ways to make certain software development tasks much easier and more streamlined for years. One example of this is low-code/no-code.

    The notion of simplifying application development and replacing software developers with laypeople (citizen developers) has been around for more than a decade now, as low-code and no-code solutions have grown more popular. These solutions have promised that companies don’t need technical talent to get their software and app projects off the ground.

    However, if you look at the impact of these solutions today, their use can result in large amounts of technical debt and almost always require the skill of experienced software developers.

    The reason? Building complex software and applications is extremely difficult; it’s an art.

    Low-code and no-code solutions have their rightful place and can make things easier if a company is looking to launch a simple app or static web page. These solutions can increase the pace of development and time-to-market and enable everyday people without any development skills to facilitate them. However, they are not actually a complete solution and often overlook aspects of development that a human software developer would typically address. Without a skilled expert involved, low-code/no-code platforms often can’t solve a unique problem a company has.

    So, how does this relate to AI code generators like ChatGPT? Here’s how.

    A Similar Situation—With One Key Difference

    When thinking about their place in the development process, AI code generators are not that different from low-code or no-code solutions. The thinking is that they will also enable non-technical individuals to create software and applications with ease.

    Yet, there is one key difference—they promise expertise, too. But is the expertise coming from the AI code generator or the person piloting it? The answer is simple; it is not from the code generator.

    There have been examples of companies and individuals that have tried using ChatGPT to build code, and they have appeared to be successful. However, without the input of the individuals using it, it never would have been able to create the code on its own unprompted.

    This means that the expertise of skilled, human software developers is still very much needed, especially when building intricate software and apps that require complex functionality such as optical character recognition (OCR), internet-of-things (IoT) connectivity and more.

    A Future With Software Developers

    Because of the expertise still required to create elaborate and innovative software and applications, AI code generators will not replace software developers anytime soon, if ever.

    The technology used in these tools is still in its infancy, presenting many lingering questions and potential challenges. We will see this confirmed by the trials and tribulations experienced by the few companies and executives attempting to replace software development teams with tools such as ChatGPT.

    Knowing AI code generators follow a similar path as low-code and now-code solutions, companies and executives should use them as developer enablement tools. These tools should complement the work of software developers by empowering them to focus on the complex tasks software and apps today require.

  • JFrog Launches New Channel Partner Program

    JFrog Launches New Channel Partner Program

    At JFrog’s swampUP event in San Jose, California, the company launched its Global Channel Partner Program. The program, led by Kelly Hartman, VP of alliances and partners, is JFrog’s first formal program to work with the channel to bring its DevOps and DevSecOps solutions to market.

    Rather than the traditional pyramid model, Hartman, who was formerly at AWS, has designed a flatter program; partners can choose to work with JFrog in a co-selling arrangement, as a traditional reseller or as part of JFrog’s government sales partners. Partners can choose which type of relationship they want to use on a case-by-case, deal-by-deal basis. This gives them lots of flexibility.

    This program is a sign of JFrog’s continuing evolution from a startup to a public company. Several of the founding channel partners in the program weren’t surprised at the announcement; the feeling was, as Mike King of IT Methods said, “They have been knocking on this door for some time.” Hartman added that the goal was not to make JFrog a 100%-channel company. Rather, the aim is to have as much business run through the partners as JFrog’s customers want while keeping the emphasis on the JFrog customer base.

    The program is primarily aimed at DevOps consultants worldwide, rather than the larger integrators, JFrog said. The DevOps consultant market is broadly fragmented, and made up of numerous sized companies – from one to two-person operations all the way up to 1,000+-person organizations, such as IT Methods.

    Hartman said she is learning from her past experience at AWS and other organizations. She has not crafted a traditional program with tiers and marketing development funds; instead, much of what partners need is built into a self-service portal, including a campaign in a box and social media kits.

    IT Methods is an ideal partner for JFrog, King said. They offer a fully-managed SaaS, single-tenant platform allowing their customers to manage their DevOps environments. IT Methods supports more than 45 DevOps tools and its major clients are large enterprises. They have offered JFrog via their platform for six years, but welcome the formal partner program and accompanying certification offered for SMEs. King said he was pleasantly surprised at the JFrog program’s maturity, considering it is a new program. He added that joint lead generation and closing capability and partner enablement offerings would put JFrog “at the head of the class.”

    The JFrog channel partner program joins their existing technology partner and cloud partner programs. In fact, Hartman said they are working with their cloud provider partners to source new channel partners. 

    It was an exciting new development in what promises to be a gangbuster swampUP here in San Jose. More developments will follow.

  • Nitric Adds Support for Additional Languages to IaC Alternative

    Nitric Adds Support for Additional Languages to IaC Alternative

    Nitric today announced it has added support for the Go and Kotlin programming languages to its application framework. The framework automatically creates code to provision infrastructure based on the way the code used to write an application has been developed.

    Rak Siva, vice president of engineering for Nitric, said that approach eliminates the need to rely on developers using infrastructure-as-code (IaC) tools to configure platforms.

    Nitric previously supported JavaScript, Python and C# along with frameworks such as Express, Fastify and Nest.js to enable infrastructure to be automatically configured based on an intent expressed in the codebase enabled by a software development kit (SDK). In effect, Nitric infers how to optimally configure infrastructure. DevOps teams can then choose to either rely on the configurations created by the Nitric framework or customize it to add support for their own policies, said Siva.

    While IaC tools have played a major role in streamlining the application development and deployment process, they are also the root cause of many cloud security incidents. Developers that use these tools typically have limited cybersecurity expertise, so the probability that cloud infrastructure will be misconfigured in a way that cybercriminals can exploit is high.

    Nitric is attempting to take the concept of managing infrastructure-as-code to the next logical level by automating the process so it can be consistently applied and managed, said Siva. That approach provides the added benefit of improving the overall developer experience by eliminating a task that most developers view as a means to a larger end, he added.

    It’s not clear how much of the cloud infrastructure that DevOps teams are relying on to build and deploy applications is misconfigured, but given the varying levels of skill among developers, there are very few organizations that have not encountered a cloud security issue. The challenge is not so much the security of the underlying platforms as it is the shared responsibility model relied on to secure these platforms. Cloud security platform providers assume that organizations that programmatically invoke infrastructure have the expertise required to securely provision it. However, very few organizations can achieve that goal 100% of the time, which results in organization having to make considerable investments in additional tools and platforms to monitor and enforce cloud security policies.

    As more organizations focus their efforts on securing software supply chains, many of them will be revisiting how cloud infrastructure is provisioned. In fact, one of the reasons platform engineering is gaining traction as a DevOps methodology is to improve the developer experience and strengthen application security.

    Cultural change, of course, is difficult. IaC tools such as Terraform are deeply embedded within many DevOps workflows, so any alternative approach to provisioning infrastructure will require time to take hold. However, as regulations that hold organizations more accountable for application security become increasingly more stringent, it’s now a question of when rather than if change will come to how cloud infrastructure is provisioned.

  • JFrog Extends DevOps Reach to Manage and Secure AI Models

    JFrog Extends DevOps Reach to Manage and Secure AI Models

    At its swampUP 2023 conference, JFrog today added additional security capabilities to its continuous integration/continuous development (CI/CD) environment as well as making it possible to manage machine learning models within the context of a DevOps workflow.

    The latest edition of the JFrog Software Supply Chain Platform adds an integrated static application security testing tool (SAST) to scan source code alongside the existing JFrog Xray tool for scanning binaries.

    JFrog has also added an Open-Source Software (OSS) Catalog to the JFrog Curation service to make it simpler for DevOps teams to discover specific packages that have been determined to be secure. JFrog is also adding Release Lifecycle Management (RLM) capabilities that enable aggregating software artifacts into an immutable software package that serves as the single source of truth as multiple iterations of an application are developed. JFrog RLM uses anti-tampering systems, compliance checks and evidence capture to collect data and insights to ensure the immutability of signed binaries.

    Finally, ML Model Management capabilities, available in beta, are being added to the platform to make it possible to store AI models, run AI models from Hugging Face, a provider of open source AI models, as a proxy in cache via an application programming interface (API) and apply DevSecOps best practices to govern, secure and ensure licensing compliance.

    JFrog CTO Yoav Landman said that as DevOps teams become more familiar with AI models, it’s becoming increasingly clear they are managed like any other software artifact incorporated into a DevOps pipeline. He noted that the approach provides the added benefit of helping to ensure AI models have not been poisoned by malicious data and prompts that would deliberately cause a hallucination.

    Most AI models today are created by data scientists using machine learning operations (MLOps) best practices that each organization defines. In some instances, those processes include what is known as a feature store that enables data scientists to track which components are being used at any given time. However, once a model is completed, it needs to be integrated into an application—a process that, from a DevOps perspective, is best facilitated by storing an AI model in a Git repository alongside other components that need to be managed.

    It’s still early days as far as the convergence of DevOps and MLOps practices are concerned. Going forward, as it becomes apparent almost every application will be invoke some type of AI model, the need to integrate these workflows is becoming a more pressing concern.

    It’s now only a matter of time before AI models become a pervasive element of the software development life cycle as they are continuously retrained and updated. It will generally fall to DevOps teams to manage the deployment and updating of those AI models in collaboration with the data science teams that train them. The immediate challenge, of course, will be to bridge the significant cultural divide between two very different types of IT professionals.

  • Survey Surfaces Spike in Generative AI Usage Across IT

    Survey Surfaces Spike in Generative AI Usage Across IT

    A survey of 800 DevOps and application security operations (SecOps) leaders published today found nearly all (97%) are making use of generative artificial intelligence (AI).

    Conducted by the market research firm Sago on behalf of Sonatype, the survey found that beyond writing code, a full 45% of the 400 security operations professionals have already embedded generative AI into their workflows compared to 31% of the 400 DevOps professionals.

    Security operations teams also reported greater time savings than their DevOps counterparts, with 57% saying generative AI saves them at least six hours a week compared to only 31% of DevOps respondents that saw the same benefit.

    The top benefits cited by security operations teams is increased productivity (21%) and faster issue identification/resolution (16%) compared to faster software development (16%) and more secure software (15%) cited by DevOps professionals.

    It’s still early days as far as embedding generative AI in workflows is concerned, but it’s clear the ability to write code faster is trumping concerns about the increased number of vulnerabilities that might find their way into application environments. The most widely used generative AI platforms are trained on a massive corpus of data that includes code of varying quality. As such, a lot of the code generated by a general-purpose AI platform will likely have as many errors, including vulnerabilities, as the code used to train it.

    The level of faith organizations will place in that code will be heavily influenced by use cases. A script used to automate DevOps workflows that are not externally facing may be one example of where a general-purpose AI platform can boost productivity. In other instances, code that contains vulnerabilities that find their way into a web application might be much more problematic.
    Despite those concerns, however, the survey finds nearly three-quarters (75%) of all respondents feel pressure to use generative AI.

    There are, of course, already large language models trained on code that has been vetted by software engineers. In the months ahead, the code generated by AI platforms specifically designed for that purpose should significantly improve.

    Sonatype CTO Brian Fox said it’s only a matter of time before IT organizations focus more on ensuring the generative AI platforms are tuned for specific tasks. In the meantime, however, application security may get worse before it gets better, with more than three-quarters of DevOps respondents noting that generative AI will result in more vulnerabilities in open source code. Only 58% of security operations professionals are similarly concerned.

    It will be up to the engineers that make up these teams to bring discipline to code quality practices and make sure the code running in a production environment is of high quality, regardless of how it was created, noted Fox. For the moment, the issue is that AI augmentation is now occurring at a faster pace than the AI advances that should one-day help DevOps teams cope with increasingly larger codebases, he noted.

    Survey respondents are also concerned about who might own the code generated by AI. A total of 40% said developers or the organizations they work for should own the copyright for AI-generated output, and most of them agreed developers should be compensated for the code they wrote if it’s used in open source artifacts in LLMs (DevOps 93% versus SecOps 88%). A total of 42% of DevOps respondents and 40% of SecOps respondents said a lack of regulation could deter developers from contributing to open source projects.

    DevOps and SecOps leads both want more regulation: Asked who they believe is responsible for regulating the use of generative AI, 59% of DevOps leads and 78% of SecOps leads said both the government and individual companies should be responsible for regulation.

    At this point, the proverbial generative AI genie is out of the bottle, so there is no going back. The issue that remains to be seen is how DevOps and security operating teams will adjust to that new reality.

  • Tips for Increasing Developer Velocity in the AI Age

    Tips for Increasing Developer Velocity in the AI Age

    These days, everyone is trying to improve release frequencies. Under mounting pressure to deliver more, many software teams are considering new strategies to enhance their developer velocity, like AI-assisted code development and platform engineering. AI has been a boon for automatic code generation, but all the code in the world doesn’t matter if you can’t deploy it into production efficiently.

    Another point is that velocity isn’t always measured productively, said Dori Exterman, chief evangelist of Incredibuild and a self-proclaimed ‘productivity freak.’ Too often, managers place value on quantitative elements, such as points per sprint and unrealistic metrics, when they really should be considering the quality of these components and how easy they are to maintain in the long run.

    I recently chatted with Exterman and other experts about tactics organizations can use to enhance their development velocity. Below, we’ll consider some helpful methods, from optimizing testing automation to creating internal development platforms (IDPs) and evolving your CI/CD processes. Essentially, optimizing the plumbing will be necessary to match the productivity of instant code generation—otherwise, the vision of continual release will remain stunted.

    New AI, Same Plumbing…

    No tech article today can mention developer productivity enhancements without a nod to AI. Just take the interest in Copilot, for example. Among GitHub Copilot users, 40% of the code they’re checking in is now AI-generated and unmodified, according to a Microsoft executive. And GitHub reported that 88% of Copilot users feel more productive when using the tool.

    In contrast to past hype cycles, the latest AI wave is not just a passing fad—it will have long-lasting effects, said Exterman. However, most of our current DevOps processes were constructed for manual code writing, not for the era of AI-assisted development.

    If you quadruple the amount of water you use but use the same plumbing system, you can’t push more water through, said Exterman. Similarly, if you amplify the amount of code you’re producing but don’t evolve your build processes, staging and testing, then DevOps suddenly becomes the new blocker.

    Ways to Accelerate Developer Velocity

    So, how can we improve development efficiency and productivity in the age of AI? Here are some actionable strategies for overcoming these bottlenecks and improving developer velocity.

    Accelerating the Plumbing

    Exterman stresses the importance of leveraging AI to enhance the foundational processes of development. This involves using techniques such as distributed computing and smart test selection to streamline build and testing processes. By optimizing these foundational steps, development teams can ensure that their coding efforts translate into efficient and rapid progress.

    Optimizing Testing through AI

    AI’s potential not only lies in code generation—it extends to optimizing testing processes. Exterman suggests tools like Launchable that allow AI to prioritize tests that matter most. This strategic approach to testing enables teams to focus on high-impact areas while maintaining comprehensive test coverage.

    Embracing Test Automation

    Exterman underscores the importance of comprehensive test automation. Rapid iteration loops are essential for maintaining velocity, and automation facilitates fast feedback cycles. This approach ensures that each code change undergoes rigorous quality checks, preventing errors from propagating downstream.

    Keeping an Eye on Technical Debt

    One of the potential downsides of increasing programming velocity is the accumulation of more technical debt. As more development occurs, the temptation to compromise on documentation, unit testing and best practices grows. Exterman emphasizes that velocity must be pursued in tandem with managing technical debt to ensure the long-term health of projects.

    Investing in Platform Engineering

    Recently, we’ve witnessed a paradigm shift toward platform engineering. Just over half of IT organizations have already embraced platform engineering, according to the 2023 State of DevOps Report. Exterman emphasizes the need for a robust internal developer platform that supports the seamless transition of code from development to staging and production. For instance, tools like Terraform and Earthly play a pivotal role in establishing testable environments and reproducible builds.

    “Bring more data services closer to the developers,” said Venkat Ramakrishnan, VP, product management and engineering, Portworx by Pure Storage. “Choose platforms that provide easy-to-deploy services that developers can consume and provide visibility and control into the underlying costs.”

    Enabling Observability

    Observability, according to Exterman, is also important for gauging efficiency. The ability to continuously monitor and log processes enhances the overall development cycle. One report from Splunk even found that 64% report their investment into observability has exceeded their expectations. Tools from New Relic and Datadog, for example, offer insights that tie quality, delivery and productivity together, enabling teams to make informed decisions.

    Evolving CI/CD With Continuous Merge

    One method to progressing CI/CD is continuous merge, a new concept that can be implemented with tools like gitStream that aims to decrease the window between a pull request, review and merge.

    “CI/CD has done wonders to improve the quality and efficiency of the software development toolchain, but it mainly focuses on things that happen after code has been written and reviewed,” said Ori Keren, CEO and co-founder of LinearB. “Continuous merge is a mindset that extends CI/CD practices further upstream to improve the quality and efficiency of the code review process. We’ve reached a point where code review times frequently cause the most significant delays in the software delivery process; continuous merge is how we fix that.”

    Using Cloud-Agnostic Platforms

    Cloud-native development has become more popular as organizations seek to design software architectures bred for the natural scalability of the cloud. Simultaneously, both technology and business motivators are resulting in a multi-cloud condition. In this scenario, IT really needs agnostic, open platforms to retain flexibility and reduce bottlenecks.

    “Enable developers to build their apps in a cloud-agnostic way so they can scale their apps globally,” said Ramakrishnan. “Much of developer and app momentum is lost when scaling apps. Helping the application teams architect it right by providing cloud-agnostic application platforms like Kubernetes enables developers to move faster, scale faster and reach their customers everywhere.”

    Measuring Developer Velocity

    The above tips should help improve velocity, but how exactly should you measure success? Well, measuring developer velocity goes beyond simply tracking the number of points completed in a sprint, reiterated Exterman. He emphasizes the importance of focusing on the ability to deliver high-quality products to the market swiftly. He underscores the need for a fast feedback loop for addressing bugs and iterating quickly. AI plays a role here, too, aiding in test writing and enabling continuous delivery.

    End Benefits of Improved Developer Velocity

    Exterman concludes by highlighting the real-world benefits of increased developer velocity. Faster bug-fixing and release cycles, particularly crucial in industries like gaming, result in improved user experiences and customer satisfaction. He emphasized the significance of aligning key performance indicators (KPIs) and objectives and key results (OKRs) with the aspects that truly matter, promoting a culture of measured and sustainable progress.

  • Despite Concerns, AI Increasingly Used to Build Software

    Despite Concerns, AI Increasingly Used to Build Software

    A survey of 1,001 senior technology executives, developers, and security and operations professionals published this week by GitLab finds 67% are working for organizations already using artificial intelligence (AI) to build software, with 60% of those respondents reporting their organizations use it every day. A full 90% said their organizations are either already using or plan to use AI to build software.

    More than half (51%) have already identified productivity as a key benefit, but 32% are also “very” or “extremely” concerned about introducing AI into the software development life cycle (SDLC).

    Those concerns included AI-generated code introducing security vulnerabilities (39%) and whether that code may not be subject to the same level of copyright protection as human-generated code (48%). A full 95% of senior technology executives said they prioritized privacy and intellectual property protection when selecting an AI tool.

    Most organizations will continue to move forward with AI, but nearly two-thirds of respondents (65%) who use or are planning to use AI for software development said their organization hired or will hire new talent to manage its implementation.

    A full 81% cited a need for training to successfully use AI in their daily work, with 75% of respondents saying their organization provides training and resources for using AI. However, a roughly equal percentage also said they are finding resources on their own.

    David DeSanto, chief product officer for GitLab, said it’s already clear that AI will have a major impact on productivity simply because 75% of a developer’s time is typically spent on activities that have nothing to do with writing actual code.

    Less clear is the amount of expertise required to use AI to build software. In some cases, development teams may need to master, for example, prompt engineering to automate DevOps workflows at scale, but in many more instances, it’s likely the DevOps platform will automatically execute the commands required.

    Regardless of approach, it’s clear that as the amount of code being created by developers starts to steadily increase, the need to leverage AI to manage DevOps workflows will become more acute. The challenge is the pace at which developers can leverage AI to write code is, for the moment, exceeding the pace at which it is being embedded into DevOps platforms.

    In addition, organizations must determine whether to converge DevOps workflows with the machine learning operations (MLOps) workflows used to build AI models that are integrated into applications. As more MLOps capabilities are added to the GitLab platform, it will become easier to achieve that goal and enable data scientists to work more collaboratively with DevOps professionals, noted DeSanto. Today, a cultural divide between two distinct IT cultures is slowing down the pace of AI innovation.

    One way or another, DevOps workflows are about to be transformed. The challenge now is determining which tasks and bottlenecks are likely to be eliminated by AI to enable DevOps teams to focus on managing applications at an unprecedented scale.

  • Internal Developer Platform (IDP) Reference Architectures

    Internal Developer Platform (IDP) Reference Architectures

    If you’ve been following the DevOps space recently, you’ve probably noticed the excitement brewing around platform engineering. Despite uncertainty in other areas of tech, it seems like platform engineering is poised for growth—Gartner even expects that by 2026, 80% of software engineering organizations will have established platform teams.

    The platform engineering idea hinges on an internal tooling system known as an internal developer platform (IDP), which platform teams own and operate and is exposed to developers to improve their efficiency, satisfaction and release fluidity. IDPs have been the talk of the town. But what does an IDP actually look like? What sort of components are they usually composed of?

    Well, at PlatformCon 2023, McKinsey representatives shared a reference architecture for building out IDPs. This framework was modeled after hundreds of internal platforms and could be a helpful benchmark for other organizations as they begin developing and standardizing their internal developer platforms.

    Below, we’ll examine the sample IDP reference architecture and its components. We’ll also have a refresher on the platform engineering concept and offer some expert tips on overcoming potential obstacles while implementing platform engineering and IDPs.

    Why Engineer Internal Platforms, Why Now?

    First, for those new to the idea, let’s explain what platform engineering is. I’ve previously defined platform engineering as “maintaining an internal self-service platform that serves the needs of developer consumers.” The practice doesn’t necessarily supplant DevOps, rather, the experts I’ve spoken to view it as the next evolution.

    This trend is essentially a response to developers overseeing more and more aspects of software life cycle management. Complexity in enterprise-level software delivery workflows has escalated in the last decade, leading to what The State of Platform Engineering Report describes as “increased cognitive load on engineers.” This is negative, as it could lead to shadow operations and burnout.

    The fact is, most developers require the same sort of technologies, which could be standardized across the board. For instance, take the consolidation around containers and Kubernetes, infrastructure-as-code and the need to implement similar build configurations and security policies across applications.

    By outsourcing the maintenance of tools for shipping and running cloud-native applications to a common platform, you take the burden off developers and free them up to code. Also, by centralizing DevOps tooling, you can enforce more governance and build out internal standards. Which should help reusability and overall deployment agility … at least, that’s the promise of it all. 😉

    Sample IDP Reference Architectures

    So, let’s turn to some real-world examples to see how this is being implemented. Mike Gatto, senior DevOps engineer, McKinsey, shared an internal platform reference architecture for AWS-specific environments:

    McKinsey’s Internal Developer Platform reference architecture

    As you can see, the architecture is divided into these subgroups. At a high level, they perform the following functions:

    • Developer control plane: This is the version control, where developers publish their code. They provide a workload specification (in McKinsey’s case, a Score file) that codifies specific configurations.
    • Integration and delivery: This includes the CI pipeline to build application code into a container and publish it to a registry. This notifies the platform orchestrator to initiate a build. Then, resources are provisioned. This area also includes a CD pipeline and infrastructure control plane.
    • Monitoring and logging: This plane includes tools for observability, analytics, and application performance monitoring.
    • Security plane: This area includes tools for secrets management, policies, and security vetting.
    • Resource plane: This plane encompasses cluster management, database tools, networking, and messaging architectures.

    “By separating developer and platform team concerns and allowing them to control the respective areas they’re experienced in separately, without requiring too much overlap,” said Gatto, “we’re making deployments more compliant and better aligned with client initiatives.”

    Humanitec has also created internal developer platform reference architectures for GCP and Azure, displayed below.

    IDP Reference Architecture for GCP
    IDP Reference Architecture for Azure

    PlatformEngineering.org has also expanded McKinsey’s original IDP reference architecture with a tooling landscape that adopts the same umbrella subgroupings but includes other pluggable tools.

    The Internal Developer Platform tooling landscape

    Roadblocks to Developer Platforms

    Starting from a blueprint could be a big help to rapidly construct IDPs. Yet, there will still be some potential roadblocks associated with adopting an internal developer experience platform. One of them is creating common platforms that actually cater well to all environments.

    “You can not and should not try to please everybody,” said Kaspar von Grünberg, CEO and co-founder of Humanitech. “Platform engineering is an 80/20 game.”

    “Platform organizations often face a lot of pressure when it comes to meeting demands for building more services that are both agile and agnostic to cloud and data center environments,” said Venkat Ramakrishnan, VP, product management and engineering, Portworx by Pure Storage. “At the same time, almost all platform engineering teams are understaffed while facing the need to support large application development initiatives and developer teams twice their size.”

    Tips to Get Platform Engineering On Track

    Reference architectures for various clouds could help cater IDPs to different scenarios. But outside of that, it will take a product mindset approach to strategically accept feedback and iterate the platform. This will involve doubling down on developer experience and adopting cloud-native foundations that can scale.

    “Platform engineering teams must consider adopting Kubernetes as it enables them to manage and deploy applications in production at scale, without having to manage applications at the individual level,” added Ramakrishnan. “Additionally, it may not be realistic to expand platform engineering teams alongside growing platforms, so teams should also consider leveraging automation and self-service capabilities to help them better manage projects at scale.”

    Is ‘You Build It, You Run It’ Dead?

    The idea of ‘you build it, you run it’ is starting to look a little antiquated next to the new and shiny platform model. It’s tough to say, but I’ll be keeping an eye on this area to see if all the effort to standardize the internal engineering approach pays off!

  • From DevOps to the Future: The Evolutionary Leap to Platform Engineering

    From DevOps to the Future: The Evolutionary Leap to Platform Engineering

    The paradigm of technology development never ceases to amaze. Over the past few decades, we’ve witnessed an unbroken chain of progress from traditional IT to Agile methodologies, from cloud computing to microservices and now, another leap is on the horizon. Enter the age of the platform engineer, a role that is swiftly emerging as a logical evolution of DevOps culture.

    From the Roots: Understanding DevOps

    DevOps revolutionized the way teams design, build and deliver software. With its advent, we saw the amalgamation of developers and operators into a single team, fostering a culture of collaboration and integration. The core idea was to tear down the traditional silos and ensure seamless interaction between different stakeholders in the development process.

    This unique approach has proven its mettle over time, bringing about shorter development cycles, higher deployment frequency, more dependable releases and quicker resolution of issues. DevOps set the stage for continuous delivery, integration and monitoring, thus speeding up the digital transformation of many organizations.

    The Evolution: Birth of the Platform Engineer

    As we delve further into the era of cloud-native technologies, containers and service meshes, the demands on the DevOps methodology have evolved. To cater to the increasing complexity and scale of modern infrastructures, we witness the emergence of a new breed of professionals, aptly titled platform engineers.

    This role is not just a renaming of the traditional DevOps engineer; it is an evolution. Platform engineers build upon the foundational practices of DevOps but go beyond by embracing a holistic view of the technology stack. They focus on creating platforms that provide a unified, consistent, and efficient environment for development and operations teams to work within.

    Platform Engineering: The Core Components

    Platform engineers possess a skillset that spans software development, infrastructure management, system operations, and, importantly, a deep understanding of the business context. They are entrusted with the design, construction and management of the underlying platforms supporting the deployment and scaling of applications.

    A significant part of the platform engineer’s role involves creating self-service infrastructures that empower teams to deliver software independently and efficiently. This can involve building and managing internal toolchains, maintaining cloud-native infrastructures, designing service observability systems and ensuring high levels of automation across the board. 

    The Future is Here: Embracing Platform Engineering

    The rise of the platform engineer signifies a shift towards more scalability, resilience and efficiency in managing modern tech ecosystems. It’s about leveraging technology to its fullest extent and creating a platform that is more than the sum of its parts. 

    As the technology landscape continues to evolve, the transition from DevOps to platform engineering may soon become the norm. It’s an exciting prospect, promising a future where innovative platforms can seamlessly integrate and orchestrate the complexities of the modern digital world. After all, in this era of rapid digital transformation, those who adapt will thrive. 

    In conclusion, the platform engineer role is not replacing DevOps but evolving from it, extending the principles that made DevOps so successful to meet the challenges and opportunities of the new tech era. As we continue this exciting journey into the future of software development and delivery, there’s no doubt that platform engineering will play an increasingly important role.