devopsy.kinsta.cloud

Category: DevOps Practice

Harnessing AI in Continuous Delivery and Deployment

In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that the continuous delivery pillar is an approach where code changes are automatically built, tested and prepared for release to production; this may be followed by continuous deployment where an approved release is automatically deployed to the production environment. The practices of the CD pillar aim to make releases and deployments less disruptive and more frequent, increasing speed and efficiency.

In this article I explain how AI can help continuous delivery and deployment processes.

Continuous Delivery Use Cases

Orchestration of Test Environments: Teams need a reliable way to prepare and manage various test environments. This includes setting up and tearing down environments, managing versioning and configuration and handling data and resources. AI tools that can help include Harness, and IBM’s UrbanCode, which can automatically spin up and down environments for testing purposes and handle configuration as code.

Execution of Various Tests: This includes system acceptance tests, regression tests, performance tests, user acceptance tests and security tests. The AI tool that could help here is Parasoft’s SOAtest. Its AI can generate test scenarios, ensure full coverage and automatically adapt to changes in the code base.

Performance Monitoring of Release-Candidate-Artifact: Tools need to assess the performance of release candidates, identify bottlenecks and compare performance against previous versions. Dynatrace is an AI-powered tool that provides automatic and dynamic baselining of application performance, helping teams to recognize when performance is lagging.

Automation of Policies for Artifact Acceptance: Rules and policies need to be defined and enforced regarding when an artifact is ready for release. Tools like Harness use machine learning to analyze past deployments and test results to predict the success of future deployments and automate the approval process.

Continuous Deployment Use Cases

Orchestration of Deployment Environments: Teams need to manage deployment environments, including setup, versioning, configuration and data management. Spinnaker is an open source tool that uses AI to manage multi-cloud deployment strategies.

Execution of Deployment Strategies: This includes executing strategies such as Blue-Green, Canary and Feature Flag gradual rollouts. A tool like LaunchDarkly can utilize AI to manage feature flags, analyze usage data and roll out features gradually.

Testing in Production: Testing the new release in the live production environment is crucial. A tool like Sentry can use AI to monitor application use in real-time and identify and alert teams to issues faster.

Restoring Production to a Prior Version: When a problem is detected with a new release, teams may need to revert to a previous stable version quickly. StackStorm is an event-driven automation platform that uses AI to define workflows, allowing you to quickly roll back to a previous version in case of failure.

Updating Documentation and Configuration Management Databases: It’s crucial to keep records up-to-date. A tool like Guru uses AI to automatically update and keep track of documentation, ensuring that it’s always accurate and up-to-date.

Challenges When Transforming CD to use AI

Here are some challenges organizations might face when transitioning their existing CI/CD pipelines to incorporate continuous delivery, continuous deployment and AI tools, along with possible solutions:

Lack of understanding of AI capabilities and uses: One of the first challenges that organizations might face is the lack of understanding of what AI can and cannot do. Some team members may have unrealistic expectations or fear that AI will replace their jobs. Regular training and workshops can help teams understand how AI can enhance their roles rather than replace them. Clear communication about the goals and benefits of incorporating AI can also help allay fears.

Data privacy and security concerns: Using AI tools often involves handling a large amount of data, some of which may be sensitive or private. There are also concerns about the security of AI tools themselves. Establish a robust data governance policy that includes procedures for handling sensitive data. Also, when selecting AI tools, prioritize those that are known for their robust security measures.

Complexity in integrating AI tools with existing systems: Not all AI tools will seamlessly integrate with existing systems and infrastructure. This could lead to technical debt and instability in the pipeline. Prioritize AI tools that have wide integration capabilities. Engage the tool’s support team or hire consultants if needed to ensure the integration is smooth and stable.

Resistance to change: The transition to a new way of working can be met with resistance, especially if team members are comfortable with the existing systems and processes. Change management strategies can help ease the transition. This can involve regular communication about the benefits of the change, training and providing support during the transition.

Cost of AI tools and training: AI tools can be expensive, and there’s also the cost of training team members to use these tools. Start with a cost-benefit analysis to understand if the transition is worth the investment. Look for AI tools that offer a good balance between cost and features. Consider phased implementation to spread the costs over time.

Dependence on vendor support: Given the complexity of AI, there may be a high dependence on the AI tool vendor for support. This could become a problem if the vendor is unresponsive or ceases to support the tool. Choose vendors who have a good track record of providing strong customer support. Also, consider tools that have a strong community around them, which can provide additional sources of help and support.

Summary

Navigating the landscape of continuous integration, continuous delivery and continuous deployment (CI/CD) pipelines can be complex, but it’s a vital process that’s being revolutionized by the introduction of AI tools. From orchestrating test and deployment environments, managing testing and deployment strategies, to automating delivery tasks and quality checks, AI is playing an increasingly critical role in streamlining and enhancing these processes.

However, as with any significant change, transitioning to AI-enhanced CI/CD pipelines is not without its challenges. This includes understanding AI’s capabilities, data privacy and security concerns, technical integration difficulties, resistance to change, cost considerations and vendor support dependencies. By identifying and addressing these challenges head-on, organizations can effectively leverage AI’s capabilities, bringing increased efficiency, reliability and value to their software delivery pipelines.

With proper planning, continuous learning and strategic use of AI tools, organizations can not only overcome these challenges but also thrive, gaining competitive advantages in their software delivery processes. The future of CI/CD is undeniably entwined with AI, and embracing this evolution is an exciting journey that holds the promise of transformative benefits.

June 29, 2023
How Platform Engineering Protects Profit, People and our Planet

Platform engineering is emerging as a way of evolving DevOps, with 94% of respondents to the recent State of DevOps report agreeing that the practice helps their organization to reap the benefits of DevOps. The business arguments for platform engineering are clear: In that same report, respondents stated that platform engineering improves efficiency (59%), speeds up delivery time (58%) and improves workflow and process standards (57%).

But in addition to the huge benefits organizations are now realizing in terms of business value, platform engineering is also pretty crucial for a business’s long-term viability. And by that, I mean that platform engineering can be inherently sustainable.

How Can Platform Engineering Be Sustainable?

First, it’s important to note that ‘sustainability’ here doesn’t just mean ‘green.’ Rather, sustainability means that an organization is able to meet the needs of the present without compromising the ability of future generations to meet their needs, too. These are needs that come in three different varieties: People, planet and profits.

This means that to be truly sustainable, platform engineering needs to deliver lasting and stable returns on things like return on investment year-over-year, improved awareness of and reduction in an organization’s carbon footprint and better governance and optimization through monitoring and analytics.

Any approach which supports business growth while simultaneously empowering employees and being kind to the planet is the dream for pretty much every organization. But how exactly can departments and wider organizations unlock all of these benefits? The answer is: There’s no magic bullet.

Sustainable platform engineering is about treating your platform as an iterative cycle: It isn’t the actual creation of the tool that matters, as much as it is the maintenance, upkeep and usability of the platform as your business moves forward. This, naturally, will take time, effort and money—all of which, it’s safe to say in the current climate, are in short supply. But it is crucial that businesses act strategically, looking for areas for improvement and paths that will all add up to a more sustainable business in the long term.

The Three Paths to Success

These paths can be divided into three main areas of focus, and the first is GitOps or infrastructure-as-code (IaC).

A tweak that every organization should start making is using Git as a single source of truth for deployments, enabling developers to work faster by empowering them to use their own code without hands-on involvement from ops teams. This could be combined with optimized infrastructure, moving toward IaC to enable faster and more efficient deployments.

These principles form the foundation of sustainable platform engineering as they protect profits, allowing the business to keep moving forward and investing in the other areas crucial for a sustainable operation. Combining IaC with GitOps ensures speed and simplicity while maintaining a high-quality end product.

Creating an optimized infrastructure is important, but just as important is empowering employees to feel good about the work that they are doing. That’s why implementing a self-service tool alongside an optimized UX is the second area of focus. This removes the pressure on those in the tech department to be infrastructure experts while erasing the need for endless tickets to be raised for issues.

By freeing up DevOps engineers and platform experts to spend more time doing what organizations need them to do, businesses can keep innovating to maintain an edge over their competitors. Self-service capabilities combined with an accessible UX are a useful combination for a much-improved developer experience (DevX).

Finally, it’s important to keep in mind that self-service isn’t just going to benefit end-users; it also has major upsides for improved governance, as well as keeping control of cloud spending and carbon footprint impact. Optimizing and iterating your platform engineering tool means that a business can keep up with the fast pace of the global tech market while also continuing to implement the latest tweaks and upgrades. It all adds up and builds on the organization’s platform engineering solution.

Reaping the Rewards of Sustainability

If an organization follows the above three paths, it is well on its way to a more sustainable business powered by platform engineering. By focusing on targeted, achievable projects to build a solid foundation, organizations can achieve big benefits for people, the planet and profit.

From an economic perspective, sustainable platform engineering ensures legacy infrastructure is modernized, silos are broken down and production is accelerated, all ensuring the business doesn’t risk lagging behind competitors. A stable and secure return on investment is key to sustainability in the medium to long term, and sustainable platform engineering ensures a business is able to weather future challenges and keep a healthy profit margin.

As we all know, underpinning any great business is the people who work there. Techs get stressed by having to interact with infrastructure they know nothing about, DevOps and specialists get stressed when those techs desperately raise tickets in an attempt to get help, and platform engineers get stressed when the weight of providing a solution to these problems rests squarely on their shoulders. Implementing a UX-strong self-service portal relieves the pressure, allowing employees to focus on delivering real value to the business through innovation. A better DevX ultimately leads to better business outcomes.

And, of course, it’s ultimately no good having a successful business if the planet we all share continues to suffer from the effects of the climate emergency. Just like a business that hemorrhages money is unsustainable, so is a planet that wastes its finite resources. By getting control of cloud usage and controlling cloud climate impact, businesses will not only be empowering their people and improving their bottom line, but they will also be making a tangible difference to our shared environment, supporting our planet as it recovers from years of climate neglect.

Platform engineering offers lots of tangible benefits for businesses, but sustainable platform engineering can be even better, not just for a business, but employees and our shared environment. It might just be time to upgrade DevOps and start thinking about building a sustainable organization that supports profit, people and the planet.

June 29, 2023
How Can DevOps Evolve? Platform Engineering

Kaylee Van De Voorde co-authored this article.

Has your team adopted a DevOps mindset? Are your engineers using tools like Docker containers, Kubernetes and Terraform? Over the last decade, many engineering teams that adopted DevOps culture and pivoted to cloud-native applications that required rapid scaling may face a new set of problems.

DevOps

DevOps practices have brought operations and software engineering teams together throughout the entire development life cycle, from initial concept through the engineering process to production support. This collaboration paved the way for iterative development: Improving velocity, providing rapid feedback and consequently improving application quality by uncovering bugs and environment requirements earlier without user impact. DevOps automation created a more “blameless” culture that improved trust, collaboration and innovation, which boosted team morale and increased engagement.

That said, DevOps teams have encountered many obstacles, including fears of job obsolescence and steep learning curves for every member. Teams that learned how to implement DevOps practices on their projects may have moved more slowly at first while learning how to work together in new ways and adopting new tools.

What is Platform Engineering?

So, what is platform engineering? Platform engineering bridges the existing gaps between software, hardware and infrastructure that come with adopting DevOps practices: Automated horizontal scaling, service discovery and cost optimization. Platform engineering makes it even easier and simpler for engineers produce high quality applications quickly by standardizing CI/CD deployments, ensuring that infrastructure is auditable and monitored, automating deployment methods and processes, providing accurate documentation and incorporating FinOps.

Platform engineering teams can make these improvements available to their teams by creating tools such as an internal developer platform (IDP) that includes APIs that expose internal tools and features within the platform.

The Next Evolution

Evolution does not mean starting from nothing.

The core tenets of DevOps practices still hold their value; aligning software engineering and operations teams to better create applications that embody business and user functionality and run smoothly within an incorporated infrastructure, automation, security and dedicated site reliability engineering (SRE). Many DevOps teams may already be moving toward an overarching platform engineering culture and simply need to refine their standards. Distinct application teams may already be building similar features to provide platform functionality; a strong indication that a platform engineering team would be beneficial.

Choosing to create a dedicated platform engineering team has tradeoffs: Building a platform engineering team pulls resources from building applications and new features that the business needs, but application teams could experience an increase in productivity if a separate platform engineering team is created. A dedicated platform engineering team can also provide clear, unified direction and nuanced goals for application teams; this is incredibly important when creating standards and internal tools.

A platform engineering team is just one way that to advance and improve engineering culture. DevOps teams that may not require platform engineering can continue their growth by refining their existing practices and patterns in their everyday work.

June 29, 2023
HashiCorp Acquires BluBracket to Extend Secrets Management Reach

HashiCorp this week revealed it has acquired BluBracket to add a set of scanning tools for discovering static secrets to its portfolio.

James Bayer, senior vice president of research and development for the Secure product line at HashiCorp, said the existing Vault platform for managing secrets is designed to enable developers to manage them as they build applications. BluBracket has developed a secrets management tool that makes it possible to discover secrets in applications that have already been deployed in production environments, he said.

The amount of secrets management-related technical debt many organizations have can be enormous, especially if they’ve been deploying applications for decades. IT teams need a tool that discovers secrets in applications that, in many cases, were deployed by application developers that are no longer with the company, Bayer added.

The BluBracket tools make it possible to discover those unmanaged secrets even before efforts are put in place to improve application security, he noted.

HashiCorp will initially integrate BluBracket’s functionality into HashiCorp Vault to expand HashiCorp’s zero-trust capabilities, and add detection and remediation workflows via additional capabilities expected later this year. That’s critical, because for decades, developers have been storing secrets in applications and forgetting to remove them before an application is deployed.

In general, HashiCorp is moving to transform its Vault platform into an orchestration engine for managing secrets regardless of where those secrets might be stored, said Bayer. That approach will enable developers to build applications and store their secrets on, for example, the Amazon Web Services (AWS) cloud in a way that can be centrally managed via the Vault platform, he added.

Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text, the need to encrypt secrets becomes a higher priority.

The core DevSecOps issue most organizations are wrestling with is how involved cybersecurity teams should be in application development. There’s clearly a concerted effort to push more responsibility for application security further left toward developers. The challenge is, even when those tools are provided, it’s not clear that developers can distinguish between the severity of one vulnerability versus another.

Conversely, most cybersecurity teams don’t really understand how modern applications are developed. That doesn’t necessary mean cybersecurity professionals need to dive deep into application development workflows, but it does mean they should, at the very least, understand how applications are constructed to make sure the appropriate security guardrails have been put in place.

Regardless of approach, it’s clear there is a need for some type of centralized security function to better ensure application security. Unfortunately, the cultural divide between application developers and cybersecurity teams remains fairly wide. The DevSecOps journey ahead will be long, as each organization determines how best to bridge that gap when the supply of available cybersecurity expertise remains constrained.

June 29, 2023
Survey Surfaces Raft of Enterprise IT Challenges

A survey of enterprise IT leaders found less than a third (32%) are extremely confident that they have the right technology, processes and people in place to execute an effective approach to IT management.

The survey, conducted by Rocket Software, polled 275 U.S. IT leaders in organizations with more than 1,000 employees. A full 93% of IT leaders are also committed to maximize the value of investments in existing platforms.

As a result, the top priorities for IT leaders are hybrid cloud computing (65%), data and content management (68%) followed by DevOps and infrastructure and application modernization, tied at 58%, and automation (57%).

A total of 62% noted they have a much greater focus on efficiency due to the economic landscape, with faster DevOps processes, automated processes and increasing overall output as the top three improvements that would be most impactful for increasing efficiency.

The survey also suggested many organizations still have much work to do to achieve those goals, with 63% of respondents spending anywhere from six to 15 hours on manual data entry and analysis each week.

Phil Buckellew, president of infrastructure modernization for Rocket Software, said most organizations are still trying to determine the right level of DevOps to adopt. Few organizations have implemented DevOps workflows on an end-to-end basis, with many employing a mix of DevOps and waterfall processes to build and deploy applications across a hybrid cloud computing environment, he noted.

Overall, IT leaders are most worried about improving overall IT performance (60%), data security (50%), process risk and compliance (46%) and the need to improve agility (41%), the survey found. Respondents also noted that they measure success within their IT organization by increased efficiency (71%), optimized resources (67%) and reduced risk (63%).

The survey makes it clear that, despite challenges, enterprise IT organizations are committed to hybrid cloud computing as they become more comfortable with using various platforms that are fit for purpose, said Buckellew.

Mainframes, for example, continue to play a major role in running online transaction processing (OLTP) applications alongside analytics applications that are now being infused with artificial intelligence (AI) capabililities, noted Buckellew.

A quarter of survey respondents also identified providing cloud applications with access to mainframe data as an area where they need additional tools, followed by automation (22%).

The biggest automation obstacles are the complexity of implementing automation (18%), resistance to process change among workforce (18%) and lack of skillsets to implement automation (18%), the survey finds.

As always, the biggest challenge in enterprise IT environments is often simple inertia. Organizations that have been building and deploying applications on mainframes, for example, have been relying on waterfall processes for decades. Many of them have now adopted DevOps processes to varying degrees, but few have completely replaced legacy approaches to building and deploying software, noted Buckellew.

It’s not likely the management of complex hybrid cloud computing environments will be simplified any time soon, but progress continues to be made. Soon, AI may automate many existing manual tasks. In the meantime, however, the number of enterprise IT organizations standardizing on a single IT platform remains few and far between.

June 29, 2023
Survey Sees Value But Limited Understanding of Platform Engineering

Platform engineering is emerging as method for managing DevOps at scale, but a survey suggested that many organizations are still not clear on the concept.

A survey of 100 DevOps engineers, platform engineers, developers, site reliability engineers and IT managers conducted by Civo, a cloud service provider, found 85% of respondents work for organizations that have partially or fully embraced a DevOps culture, with nearly two-thirds (65%) identifying platform engineering as the next evolution of DevOps. Nearly, a third (30%) of respondents work for organizations that are already currently evaluating whether they should adopt platform engineering.

Overall, the survey found 50% of the respondents at organizations that have adopted platform engineering reported improved standardization, with 43% also seeing faster product delivery.

However, only 41% of the respondents in DevOps roles that were familiar with platform engineering said they had a moderate to high level of familiarity with the concept.

Saiyam Pathak, director of technical evangelism at Civo, said the survey makes it clear that, in terms of understanding how platform engineering best practices should be implemented, there is need for more clarity. Many organizations initially adopted DevOps to spur innovation, so any approach to centralization shouldn’t come at the expense of developer productivity, he noted.

Historically, DevOps adoption of DevOps workflows in most organizations has been driven from the bottom up. As a result, it’s fairly common for multiple application development teams within an organization to have adopted multiple DevOps platforms to manage workflows. Advocates for platform engineering are making a case for eliminating many of those redundant platforms in favor of, for example, a single continuous integration/continuous delivery (CI/CD) platform that serves as a corporate standard.

At the core of those efforts is the assumption that centralization will reduce costs by eliminating redundancy. At a time when more organizations than ever are sensitive to the cost of IT, there is always going to be a natural tendency to rationalize platforms. Challenges arise, however, when centralization results in a loss of flexibility. Many of the teams adopt DevOps because they want to be able to add and replace tools as they see fit. If there is a corporate standard that narrows their tool options, those teams may start to look for ways to do an end-run around the corporate standard.

The philosophical IT battle between advocates for centralization and proponents of decentralization has been around since the first PCs showed up in enterprise IT environments. As always, organizations need to strike a balance between both extremes, said Pathak.

It’s not clear how much platform engineering might accelerate the pace at which applications are built and deployed, but the total cost of DevOps should decline as various tools and platforms are consolidated. The challenge, of course, is that centralizing DevOps workflows is likely to disrupt the application development workflows on platforms that may about to be rationalized.

Regardless of what platforms become the corporate standard, the one thing that is certain is the cultural challenges associated with successfully making that transition will loom large within most organizations.

June 28, 2023
How IT Services Can Embrace Platform Engineering

We are all familiar with DevOps as a newer approach to software development. The concept is designed to enable developers and IT operations teams to work together. Platform engineering, on the other hand, is a more mature, older approach that has become new again.

Platform engineering, at its core, is the concept of productizing your internal development platforms to make it easier for developers to work. It is an emerging technology approach that can help accelerate the delivery of applications and the pace at which they produce business value. More recently, companies have grown their complex software architectures which have created silos for the teams that manage these various architectures. There may be multiple teams with various specialized skill sets and a single DevOps engineer who takes care of the continuous integration (CI) jobs to deploy and release to production.

Now let’s imagine that you have 10 squads that focus on building and maintaining different applications. Now all of these teams are building and operating 10 different platforms to run their applications, which creates inefficiency across the teams and reinforces silos. In this scenario, teams may spend half of their time building and maintaining the platforms instead of delivering business value. This creates a large cognitive load on developers.

This model becomes very hard to scale. Even though you have these squads managing their own infrastructure and platforms, you may find gaps because there is no centralized standard. So how do platform engineering concepts help with these complex landscapes and boost efficiency?

The Consulting Mindset

Platform engineers take all of the tools used to run an application across your various teams and standardize their usage. This enables self-service capabilities for your engineering organizations. Platform engineering can help centralize how you are deploying and running your applications across a complex software landscape. This includes not only the standardization of tools being used but also documentation and processes.

Establishing platform teams requires a consulting mindset and thinking about what resources, services and components can be centralized to better serve the rest of the organization. Some may refer to this as the center of excellence (COE) model, or simply IT for IT. This boosts efficiency and cuts down the time to delivery by providing a central set of tools and platforms for your engineering organization. Many may see platform engineering as a cost center, but the ROI is higher-quality releases, a standardized way of developing and delivering software and shorter delivery times.

Applying This Concept to IT Services Firms

In my consulting days, I worked for firms that focused on delivery for the Salesforce platform. We often had complex projects that we needed to deliver for large enterprise customers who had multiple applications integrating into their CRM. Each project team often had a different way of delivering and developing based on the customer’s needs. This created specialized skill sets, but we had no standard way of developing and delivering. Investing in a platform engineering team to support the delivery organization can add immense benefits for large consulting firms, enabling them to standardize the tools and platforms being used to run and deliver applications at scale.

Having a centralized place for your developers to go for process, documentation and tools to help them build and run applications can increase the speed at which they deliver. The efficiencies gained in having a smoother self-service flow for your developers and cutting down the delivery time are worth the investment. It brings significant long-term value that the customer will experience long after the engagement is completed, which can greatly impact future considerations for your firm.

IT services firms should find ways to align and centralize their technologies with platform engineering concepts. You may not be able to exactly build out an internal developer platform, but adopting some of the core concepts will help you be more efficient as an organization. For example, if you are an IT services firm specializing in delivering applications on the Salesforce platform, look for extensible DevOps platforms that can support your development organizations.

Also, look for ways to enable a self-service workflow to make it easier for your developers to work and scale. This may include investing in a platform engineering function to support the rest of the delivery organization. By establishing platform engineering concepts, you will be able to cut down the delivery time and create consistency in how you deliver and deploy applications for your customers.

June 28, 2023
Must You Collect All That?

It is interesting that we no longer consider teams that super-tool their apps as being slightly ‘off’ or, working in a field where systems were mission critical, even life-and-death. Now, we all are collecting and reporting data points in real-time across not just the SDLC, but across the entire environment. It is wild the amount of data available to the average DevOps team about what is going on with their applications. But it’s not all being used.

No, seriously, it is unreal. Let me offer two anecdotes that explain why I know you’re not using it all.

Most of my regular readers know that I worked at F5 for years, the first couple on the DevCentral team, doing the Dev part. Their flagship product, the BIG-IP, collected an incredible amount of super-granular data. I am not exaggerating when I say an incredible amount. They had data points from the wire up to the traffic routes through the load balancing algorithm to nodes. And it was (and likely still is) all available to users via APIs. Whatever data was needed about traffic passing through the BIG-IP or the nodes behind the BIG-IP and the connections in between users and those nodes, you could get.

One of my projects was to offer a simplified interface to the APIs. They were complex and granular, and customers wanted fast and easy, so I was publishing code that worked as an intermediate layer.

Note: F5’s APIs, like everyone else’s, are far more advanced today than they were then, and it is easier to do what you need to do because they took the “create a user layer” part seriously. It’s complex machinery so it still has complex APIs, but accessibility is way up from those early days.

Anyway, BIG-IP collected so much data that I could not name all of the fields, let alone when each one was pertinent. I gave up trying after a while, because if a board-level engineer needed a data point, the idea at the time was “Why not expose it?” so ‘number of connections to a given node’ under this algorithm was hidden among things like ‘microseconds to connect to DNS on that connection’ (I’m making those up; it’s been years). Some were terribly useful to end users and others were not. All were accessed in the same way, and learning by experimenting was the only real way to tell the difference.

Users did not need all of that data. Users did not need the complexity and obfuscation created by supporting all of that unnecessary data.

My other example is a massive system of interconnected IoT devices that were centrally connected/controlled with a private, specialized network to manage them (actually, there were several different networks on several different mediums, and that matters where data points are concerned).

When setting this system up, we estimated about half a million IoT devices with capabilities that ranged from passive monitoring to active controllers of physical devices. Four different communications mechanisms, a couple dozen different devices, every major (and a couple minor) databases and command-and-control software on every major OS, managing from a handful to hundreds of thousands. And all of these were super-tooled because the IoT network was mission-critical. Our databases and the infrastructure to support/protect them were a major part of our data center budget because of the amount of data.

The amount of data was a flood. The management software was developed by different companies with different transports and endpoints in mind, meaning each had a different dataset. Once all of the networks were running satisfactorily, our next immediate project was to create a unified dataset for reporting and troubleshooting. I was in charge of IT, but the top-level person–because each of those half a million devices was a physical install–was a physical engineer. We fought non-stop about what was important. I was trying to map and convert datapoints between systems; he was trying to maximize data available for reporting up. He often said, “Well no, we don’t need that today, but we might.” This put us in a zone where “number of devices on this system” was on par with “attenuation of the communications line to the nodes on this physical subnet.” Totally unworkable, and our compromise was to put together a small IT team to put a layer over all that raw data and offer an intelligent interface side-by-side with data dumps.

We are there again today. I hear many of my friends in the enterprise space saying, “Because of ML, we might need that data and storage is cheap.” I disagree. Storage is an overhead that is wasted if you are not actively using the data. We are past the “all data is good data” craze; it’s time to adapt. Useful data that expands insights is all you need tooling for. Report data that will help solve problems, and if the team finds tomorrow that it needs a data point that is not currently collected, it can be added in.

There is room for debate here–the rate of change for ML systems (please stop calling them AI; they’re not, yet, and we’ll need that word when they are cognizant) means that there is a reasonable argument for “all of the data.” And I’m not proposing limiting data collection. Honestly, application security specifically and enterprise IT security overall has benefitted from datapoint sharing between formerly separate market spaces. If the SCA scan shows X framework is used, then the IAST can narrow down tests to those that look at X and not its competitors, for example. But honestly, don’t drown yourself in a data lake when all you need is a fish tank where you can see all the guppies.

And keep rocking it. Even if you entered IT two years ago, you are now a seasoned vet and things have changed–beyond all of our expectations, I’d say. Yet you’re still plugging away, keeping the enterprise running. Don’t stop—just try to keep the data hoarding to a reasonable level and make sure the data you have is being used, whether as useful feeds to an ML tool or as consumable information for other people/systems.

June 28, 2023
Mendix Embraces DevOps for Next Era of Low-Code App Development

Mendix, a subsidiary of Siemens, today updated its namesake low-code application development platform to add support for DevOps workflows and make it simpler for developers to compose applications and embed artificial intelligence (AI) capabilities.

Sheryl Koenigsberg, vice president of product marketing for Mendix, said Mendix 10 makes it possible to use Git repositories for version control along with Mendix Pipelines, currently in beta. Mendix Pipelines is a continuous integration/continuous delivery (CI/CD) environment that will be embedded in the low-code platform. In addition, Mendix is adding support for Webhooks that can be used to integrate Mendix with existing CI/CD platforms.

Mendix has also added a Solutions Kit, now generally available, to make it possible to customize applications in a way that ensures those changes will be preserved as application environments are upgraded.

There is also now a Portfolio Manager tool to track projects and a connector for integration with the Jira project management software from Atlassian.

Later this year, Mendix will also make generally available Adaptation Insights to provide insights into application extensions.

In the future, developers will be able to leverage an extensibility framework to tailor the Mendix Studio Pro integrated development environment (IDE) by adding their own plugins, wizards, editors and third-party integrations. Later this year, Mendix 10 will also add, in beta, a version of its Studio Pro IDE for MacOS.

The Mendix approach to composability is also being extended to incorporate AI. The company is adding Mendix Assist, a bot that generates validation logic for data entry. This module is the second AI capability that Mendix has developed after previously previewing Mendix Chat, a tool based on a large language model created using Mendix data that will be integrated into the Mendix integrated development environment (IDE) later this year. Mendix Assist will be incorporated into Mendix Chat.

Mendix is also developing additional LLMs for creating applications and will as part of its commitment to composability plans to make it possible to integrate third-party AI services and LLMs into the Mendix Runtime to create “smart apps.” AI models will be converted to the Open Neural Network Exchange (ONNX) format, an open standard for machine learning models, to provide that capability.

In addition, Mendix is adding support for event-driven architectures via Business Events and an Event Broker, to build more complex applications.

Other capabilities being added to Mendix 10 include updated REST and database connectors, support for visual data filters, rich properties and design controls, a Start from Spreadsheet tool, end user survey tools, a PDF document generator and a revamped set of governance and risk assessment tools.

Finally, Mendix is adding a Terraform module to make it simpler to deploy its low-code platform on the Amazon Elastic Kubernetes Service (Amazon EKS) in addition to providing a reference implementation for building private clouds to develop applications using the Mendix Cloud service.

As AI-infused low-code applications are developed faster, it’s not clear to what degree organizations are prepared to embrace the inevitable disruption that will ensue. However, the one thing that is clear is that the DevOps workflows used to deploy these applications at scale will soon be put to the ultimate test.

June 27, 2023
Design for DevOps: Using AI in App Design and Enhanced CI/CD Pipelines

In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that design-for-DevOps practices, a DevOps pillar, involves designing software in a way that supports the DevOps model and CI/CD pipelines. This can include aspects like microservices architecture, modular design and considering operability and deployability from the earliest stages of design.

In this article, I explain how AI can be used in the software design phase to enhance the performance of DevOps and CI/CD pipelines.

AI-Assisted Code Review and Quality Assurance: AI-engineered tools such as DeepCode and Kite can detect bugs and security vulnerabilities in the codebase and suggest improvements.

Infrastructure-as-Code (IaC): IaC tools such as Terraform, Ansible or Chef enable automation and standardization of the IT infrastructure and enhance the efficiency of DevOps pipelines by supporting rapid, consistent and repeatable deployments and rollbacks.

Serverless Architectures: Developers can build and run applications without thinking about servers. This means less time spent on managing infrastructure, updating servers and debugging system issues. AWS Lambda, Google Cloud Functions and Azure Functions are all examples of serverless computing platforms.

Containerization and Orchestration: Tools like Docker provide an easy way to package and distribute applications across various environments using containers. Kubernetes, on the other hand, can help manage these containerized applications at scale. Containerization and orchestration help maintain consistency across environments, simplify scaling and speed up the CI/CD process.

Microservices Architecture: Small, independently deployable services can significantly improve the speed of development and deployment cycles as well as the reliability of applications.

A/B Testing and Feature Flagging: Aided by AI-engineered tools, A/B testing and feature flagging can help to test new features in production with a small subset of users, making the release process less risky and more controllable.

AI-Powered Performance Optimization: Tools like Akamas use machine learning to autonomously optimize the configuration of software applications, dramatically improving the performance and efficiency of CI/CD pipelines.

AI-Driven Test Automation: AI-engineered tools can help automate the testing process. They can predict which tests are likely to fail and need to be executed first, optimize test suites and automatically generate tests.

Adopt Observability: Use AI-powered tools for monitoring, logging and tracing to gain a comprehensive overview of the system. This data-driven approach can provide insights that can lead to performance improvements.

Predictive Analytics: Tools that use AI can predict possible failures in the development process or in the software itself, which saves resources and helps developers anticipate and mitigate problems before they occur.

Challenges and Solutions

Challenges faced when implementing each of these strategies, and recommended solutions for overcoming them are described below.

AI-Assisted Code Review and Quality Assurance: Developers may resist due to fear of relying too heavily on automation and skepticism about the accuracy of the tools. Begin with smaller, non-mission-critical projects and gradually scale up. Continuous training and iterative feedback improve the accuracy of the tools.

Infrastructure-as-Code (IaC): The learning curve can be steep and managing IaC can require new skills. Invest in training your team or consider hiring experts. Start with simpler projects and scale up.

Serverless Architectures: Debugging can be difficult and there can be concerns about vendor lock-in. Use application performance monitoring tools specifically designed for serverless environments. To address vendor lock-in concerns, use abstraction and containerization methods.

Containerization and Orchestration: Containers require a different mindset and skillset compared to traditional virtualization. The initial setup and learning curve of Kubernetes can be steep. Training or hiring specialists is key. Starting with smaller projects can help in getting familiar with this new way of managing applications.

Microservices Architecture: Implementing microservices can add complexity, especially around inter-service communication, data consistency and managing multiple databases. Use tools and practices designed for microservices such as service meshes and API gateways. Also, ensure each service is as decoupled and cohesive as possible.

A/B Testing and Feature Flagging: This requires a mature deployment pipeline, and managing feature flags can be complex. Tools that manage feature flags can simplify this process. It is also essential to ensure a strong culture of testing and to have good monitoring and rollback capabilities in place.

AI-Powered Performance Optimization: The accuracy and effectiveness of these tools depend heavily on the quality and comprehensiveness of the data they receive. Ensuring good data hygiene practices and comprehensive observability measures is crucial.

AI-Driven Test Automation: AI testing tools can be seen as a black box, and their effectiveness is heavily dependent on the quality of the data they are trained on. As above, good data practices and thorough understanding of how these tools work is necessary.

Adopt Observability: Implementing observability can require significant changes to application design and development practices. Start small with key applications or services and gradually increase scope. Training or hiring for the necessary skills is also important.

Predictive Analytics: Building effective predictive models requires high-quality, comprehensive data and skilled data scientists. Invest in data management and data science capabilities. Using pre-built models and tools can help to get started.

Roadmap to AI-Assisted DevOps Culture

Implementing these strategies can be complex and vary significantly depending on the specific context and needs of an organization. The following is a generalized roadmap that can serve as a starting point.

Step One: Assessment and Planning

Conduct a thorough assessment of your current state, including the technologies in use, the skills of your team and the specific needs and goals of your business. Prioritize the strategies that are most likely to deliver value for your organization, taking into consideration the investment required and the readiness of your team. Create a detailed plan for implementing each strategy, including milestones and metrics for success.

Step Two: Build Skills and Infrastructure

Based on your plan, invest in the necessary training for your team. This could involve in-house training, hiring new team members with specific skills or contracting with external consultants or service providers. At the same time, start building the necessary infrastructure. This could involve setting up new servers, purchasing software or services or configuring existing resources.

Step Three: Pilot Implementation

Begin by implementing the chosen strategies on a small scale, ideally in a non-critical project or environment. Monitor the progress closely, gathering data on the impact of the changes and any problems that arise.

Step Four: Review and Iterate

After the pilot implementation, conduct a thorough review of the outcomes. Based on this review, iterate on your strategies and plan.

Step Five: Scale Up

Once you are confident in the effectiveness of your strategies, begin scaling up.

Step Six: Continuous Improvement

Regularly review your progress, keep an eye on new developments in the field and be prepared to adjust your strategies as needed.

Benefits

Implementing the roadmap as described will bring several benefits to the organization:

• Improved Efficiency: Automation and streamlined processes, reduces manual effort and leads to increased productivity and more efficient use of resources.
• Enhanced Quality: By using AI-assisted tools for code review, testing and performance optimization, the quality of the software can be significantly improved.
• Increased Agility: Strategies like IaC, serverless architectures and microservices make it easier to adapt to changing requirements and market conditions.
• Greater Reliability: By implementing robust testing, monitoring and rollback capabilities, the reliability of the software is enhanced.
• Better Decision Making: By adopting data-driven strategies like observability and predictive analytics, the organization gains deeper insights into its processes and outcomes.
• Risk Reduction: Through A/B testing, feature flagging and predictive analytics, potential issues can be identified and addressed before they cause problems.
• Skills Development: Investing in an organization’s people has many lasting benefits.
• Competitive Advantage: Adopting leading-edge practices and technologies will create competitive advantages.

Summary

This article provided guidance on crucial strategies for optimizing application design and development processes to enhance DevOps CI/CD pipelines. AI-enhanced strategies included AI-assisted code review, IaC, serverless architectures, containerization, microservices, A/B testing, AI-powered performance optimization, AI-driven test automation, observability and predictive analytics. Each of these strategies, while powerful, poses unique challenges such as resistance to adoption, complex learning curves and data dependency. Solutions to address these challenges focused on the importance of training, initiating less complex projects, maintaining good data hygiene practices and potentially hiring specialists.

To practically implement these strategies, an example roadmap starts with an initial assessment and planning phase to understand the existing status and prioritize strategies. This is followed by skill development, a pilot implementation phase, a review and iteration phase, finally scaling up successful strategies. A successfully executed roadmap promises benefits such as improved efficiency, enhanced quality, increased agility, greater reliability, better decision-making, risk reduction, skills development and a competitive edge. The implementation of this roadmap necessitates careful planning, continuous learning and iterative improvement but holds the potential for a transformative impact on the organization, truly embodying the principle of ‘Design for DevOps.’

June 27, 2023