devopsy.kinsta.cloud

Tag: devops

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
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
How to Empower DevSecOps in a Complex Multi-Cloud Landscape

Organizations are embracing cloud-based application delivery for speed of delivery and scale. However, the proliferation of multi-cloud systems to access and maximize the cloud’s capabilities is driving complexity in IT environments. Many organizations do not consider how multi-cloud adoption is expanding their attack surface—and the risk is growing: The 2023 CrowdStrike Global Threat Report found cloud exploitation cases grew by 95% year-over-year and cases involving threat actors targeting cloud environments were up 288% from a year prior.

The expansion of cloud infrastructure and services has increased the pressure on organizations to protect assets within their multi-cloud environments. To alleviate this burden, more businesses are turning to DevSecOps, a practice that incorporates security at an earlier point in the development life cycle. This practice of shifting left helps improve the quality and reduces risk of applications, as well as makes the delivery of these applications more efficient since any potential issues are found earlier in the development process.

DevSecOps is being adopted rapidly by organizations today to address the expanding array of threats and increasingly sophisticated attacks targeting multi-cloud environments. However, securing the cloud can be tricky due to its dynamic nature and multi-cloud makes shift left security even more complex. For DevSecOps to truly be effective, here are three things that organizations should consider doing.

1. Strive for Complete Visibility in a Multi-Cloud Environment

It is important that DevSecOps teams have a comprehensive understanding of their multi-cloud environment. Without it, they will not be able to identify a variety of security risks including vulnerabilities, privileged credentials, misconfigurations and other threats that may leave their organization’s cloud assets vulnerable.

The best way to get full visibility across multi-cloud environments is through a cloud security posture management (CSPM) tool. With a CSPM tool, DevSecOps teams can identify misconfigurations and proactively detect threats. In addition, DevSecOps teams should also use a cloud infrastructure entitlement management tool (CIEM) to manage identities across all of their cloud infrastructure resources. The primary goal of a CIEM tool is to mitigate the risk that comes from the unintentional and unchecked granting of excessive permissions of user credentials.

2. Visibility and Compliance Do Not Guarantee Security

Organizations need to develop a comprehensive security strategy to mitigate issues within the development process. This may include implementing tools, automation and standards to enable developers to follow the desired security behavior. These approaches reduce developer friction, as well as diminish the likelihood that unsafe or default configurations will be used. Historically, DevOps teams have pushed back on integrating security since their concern is that it slows down the development lifecycle. However, DevSecOps is gaining traction in recent years because organizations are realizing integrating security sooner in the development lifecycle is more efficient than reactively patching problems as they arise.

A tool that DevSecOps teams should look to leverage is cloud workload protection (CWP) because it offers breach protection for workloads, containers and Kubernetes, while enabling them to continue to build, run and secure applications with speed and confidence.

3. Create Consistency With Security Tools

Ideally, organizations should opt for a single platform that consolidates capabilities such as CSPM, CWP and CIEM. The reason for consolidation is to eliminate security gaps from having multiple security solutions. As a result, DevSecOps teams should turn to cloud-native application protection platform (CNAPP) tools to create more consistency within the multi-cloud environment.

Securing multi-cloud environments can be complex. By empowering DevSecOps teams using these best practices, organizations will be able to move faster than today’s adversaries and have the agility to quickly adapt to present and future cybersecurity challenges in their multi-cloud environments.

June 23, 2023
How to Avoid Risk When Using Multiple Low-Code Platforms
Organizations are still increasing their use of low-code/no-code (LCNC). But this adoption isn’t always consolidated around one tool—frequently, multiple low-code/no-code platforms are used under the same roof. In fact, Gartner predicts that by 2024, 75% of large enterprises will be using at least four low-code development tools for both IT application development and citizen development initiatives.

Utilizing multiple low-code/no-code platforms simultaneously introduces some security concerns. This is partially due to a lack of standard policies to govern different platforms in the same way. Low-code platforms are often incompatible with traditional IT security processes, like vulnerability scanning, manual code reviews and runtime security monitoring. Organizations going all-in on citizen development need safe ways to use low-code/no-code platforms. So, how can they safely enable this innovation without hindering productivity?

I recently met with Michael Bargury, CTO and co-founder, Zenity, about securing LCNC systems. Bargury, who oversees the OWASP Low-Code Top Ten list, has significant insight into both the benefits and drawbacks of low-code/no-code platforms. Below, we’ll review the potential risks of using multiple low-code platforms and consider ways to mitigate these concerns.

Why Companies Have Multiple Low-Code Platforms

Interest in low-code has been rising, and low-code/no-code adoption continues to accelerate across enterprises. According to Bargury, large enterprises often don’t get a choice in the matter—low-code tools are arising organically, and it’s challenging to keep a lid on their proliferation.

One way this occurs is that low-code becomes embedded into the SaaS platforms everyone already uses. Software platforms integral to business operations, like Salesforce, Microsoft Office and ServiceNow, have arguably mutated into low-code platforms, making them more like cloud providers than SaaS vendors, said Bargury.

The other way low-code platforms emerge is through bottom-up transitions, says Bargury. This could be a specific knowledge worker working in a subset of the business to automate a domain-specific operation or integrate various tools. Then, there are the platforms, like OutSystems, Mendix or Mulesoft that specifically target professional developers.

Organizations going all-in on citizen development may build a center of excellence and focus efforts on a single platform. And low-code platforms targeting developers will sometimes encourage more consolidation. Yet, “different platforms solve different use cases better,” explained Bargury. As a result, you will usually have a few converging in the same enterprises.

Potential Security Concerns of Multiple Low-Code Platforms

The emergence of low-code is similar to the bring your own device (BYOD) movement. IT and security leaders fought to avoid it at one point, but nowadays, everyone does it. So, what are the security implications if low-code becomes similarly ubiquitous? Well, no matter how it’s generated, low-code-bred programs are still applications susceptible to the same logical problems. And unfortunately, compared to your typical traditional code development life cycle, low-code development is fraught with discrepancies, says Bargury.

Immature CI/CD Pipelines

Some platforms do not offer the kind of mature CI/CD process one would expect from a software development platform. For example, there may be no way to create tests or separate your environments. Since there’s no coherent and consistent way to push code from development into production, you lack a way to apply secure development across platforms. “You don’t have a way to ensure every piece of software is up to your standards,” said Bargury.

Opaque Underyling Codebases

In traditional software development, you apply your own security reviews to ensure applications don’t contain risks. This includes shift-left scanning, security gates, manual reviews to catch mistakes early on and runtime scanning to catch unknown vulnerabilities in production. But there aren’t always parallels in low-code development. Low-code solutions typically have their own way of doing things with fewer standards, and they avoid exposing the underlying code and Git, said Bargury.

Lack of Visibility

As such, with low-code obfuscation, you lose a degree of visibility into how an application runs. Logs may be insufficient or wholly inaccessible. It’s also tricky—or at times impossible—to set up runtime monitoring, let alone scan various platforms. This means that low-code users can’t leverage powerful observability tools to identify errors and remediate security holes.

Lack of Unified Policies

Finally, establishing common authorization and permissions across multiple low-code development platforms is another hurdle. Since low-code vendors have their proprietary building blocks, you’re unable to leverage something like OPA or Kyverno to create and unify policies. Lacking shared policies across tools makes it challenging to verify that best practices have been implemented, says Bargury.

How to Secure Multi-LCNC

Low-code can grant much creative potential. But, knowing the above risks, what should IT be doing to reduce risks around low-code—especially when using multiple platforms? Well, Bargury shared several steps to help cybersecurity leaders start safely addressing the emergence of increasingly low-code capabilities.
1. Take low-code development under the application security umbrella. First, low-code must be brought under the security umbrella, if it isn’t already. “It should be part of their mandate,” said Bargury. Shift the responsibility to professionals well-trained in resolving threats.
2. Understand your surface area. As a basic security tenant, you can’t secure what you don’t know. Thus, Bargury recommends increasing your visibility into each low-code platform by collecting logs when possible and centralizing your analysis.
3. Create automated guardrails. Next, it’s critical to identify your risks and set guardrails for your low-code users—especially when citizen development is involved. The OWASP framework provides a good overview of common risks and mitigation advice across robotic process automation (RPA), integration and low-code. In general, it’s important to design permissions with the rule of least privilege in mind. This can help reduce the chance of vulnerabilities like LCNC-SEC-03: Data Leakage and Unexpected Consequences and LCNC-SEC-01: Account Impersonation.
4. Address gaps within the development life cycle (SDLC). Lastly, low-code platforms often provide the building blocks to secure applications, but it’s still up to you to ensure they are safely used. Cybersecurity teams should continually audit the low-code SDLC to ensure holes don’t persist.
You’re Responsible for Securing Low-Code Development

Low-code development platforms aren’t 100% safe from harm. It’s not out of the question for hackers to abuse low-code platforms and turn them against their owners. For example, Microsoft’s Detection and Response Team (DART) reported how a hacker group used entry to a low-code tool to remain hidden within an organization for six months, using credential stuffing to access an administrative account. By creating automations, they were able to use internal discovery tools and exfiltrate secrets and data that could have been used for privilege escalation.

As you can see, there are legitimate concerns for low-code, especially at scale. However, security responsibility is not always that transparent. To date, there isn’t an equivalent of a shared cloud responsibility model in the realm of low-code development. As such, at the end of the day, you need to take the reins to own the applications that you build and ensure everything is secure.
June 23, 2023
Noname Security Looks to Shift API Security Testing Left

Noname Security today made generally available an update to a tool for testing application programming interface (API) security that promises to make it easier for DevOps teams to ensure APIs are secure.

Filip Verloy, a field CTO for Noname Security, said Active Testing V2 is purposely designed to make it simpler to integrate API testing within a larger DevSecOps workflow.

Version 2 of Active Testing, for example, provides additional integrations with continuous integration/continuous deployment (CI/CD) platforms along with automated API discovery tools.

Other capabilities included in the latest release are tools to automate API response inspection, troubleshooting, classification and vulnerability discovery.

Finally, Noname Security has also added support for GraphQL-based APIs alongside REST APIs.

In total, there are now more than 160 API security tests that can be employed on an API testing tool that Noname Security developed to enable it to build Active Testing, said Verloy. In effect, Active Testing is an extension of that core API testing tool, he noted.

The biggest issue DevSecOps teams encounter when testing API security is that most legacy tools are not designed to provide any visibility into the business logic used to construct APIs. As such, there is a need for API security tools that can be easily integrated within DevSecOps workflows to discover issues before APIs are exposed in a production environment, he noted.

While a lot of progress has been made toward securing software supply chains, APIs have generally not received enough attention. Developers typically create APIs, but they don’t typically assume responsibility for managing and securing them. As the number of APIs within organizations continues to proliferate, there is a growing need to centralize API management and security.

Historically, developers have assumed that cybersecurity teams were making sure APIs are secure. Cybersecurity teams, conversely, assumed that the developers that created APIs would be responsible for securing them. DevSecOps best practices make it possible to now extend responsibility for security further left toward developers in a way that enables cybersecurity teams to define the policies and controls that should be used, noted Verloy.

It may a while before every organization masters the all the nuances of DevSecOps, but as pending legislation that requires organizations to better secure software supply chains becomes law it’s only a matter of time before organizations revisit API security—if they have not done so already.

In the meantime, cybercriminals have already discovered that insecure APIs provide a convenient mechanism for exfiltrating data that they can then sell or hold for ransom. The number of rogue and zombie APIs that are unknown or that have been forgotten has become a major cybersecurity issue. Ideally, DevSecOps teams would not only test the security of APIs before they are deployed but would also address a significant amount of technical API security debt that has already accumulated.

One way or another, API security is going to become a significant issue in the weeks and months ahead. The issue now is how to address it before it gets any worse.

June 21, 2023
Developers’ Role in Protecting Privacy

We live in a world where we always expect things to happen seamlessly. Every time somebody walks into a café and signs in to the free WiFi and opens their Instagram or TikTok to stay up-to-date with trends and friends or retrieves a discount from a retailer by joining their newsletter circulation, rarely do they stop to think about how that convenience and value is derived.

Technology is the key enabler working away in the background, and developers and DevOps teams are making that happen. Underneath the slick interfaces of the apps and websites that provide these highly efficient and personalized experiences is a complex machine that relies on data to fuel it, built by developers and delivered by DevOps teams.

In many ways, data is a two-way exchange, and those end-users that are aware of this give and take appear to be happy with how the relationship works.

Indeed, several surveys in recent years suggested that the majority of consumers are happy to share their data with companies if it improves their experience. Furthermore, a significant minority are still comfortable if they have no control over who sees their data, there is no clarity around how data is stored and used, even if the organization in question has a poor reputation for data privacy.

The Privacy Balancing Act

So, if most people already accept data trade-offs in some shape or form, should developers still care about building applications and solutions that guarantee data privacy?

The short answer is yes, but as developers, that involves a tricky balancing act.

Although sharing data has become commonplace in exchange for benefits and value, consumers are becoming more aware of privacy issues. Take the EU’s General Data Protection Regulations (GDPR) as an example. Over the past five years, awareness has more than doubled in notable European markets such as the UK, Spain, Germany, the Netherlands and France.

Meanwhile, there is also commercial pressure, as employers rely on developers to innovate to remain profitable. At the same time, customers expect brands to be responsible with their data, and failure to do so at the expense of trying to commercialize a new application could be detrimental. Indeed, while the pandemic may have ushered in significant changes and altered consumers’ attitudes toward data privacy, end users remain unwavering about the importance of security.

Maintaining this balancing act is becoming increasingly complex to achieve. However, the question of data privacy is becoming a key business priority, and that means developers have a big opportunity to show their commercial value to their organizations. Indeed, companies cannot afford to get the balance wrong, and developers are central to creating the perfect formula.

In fact, the privacy conundrum has been around for a long time.

When the internet was created, privacy was not considered an issue because all content accessed online was deemed to be public. Nothing was encrypted; the introduction of email complicated things, not least because anybody on the internet could, theoretically, intercept personal data and read private messages.

This prompted the emergence of the cypherpunks, a group of cryptographers who began to contemplate what the future of digital privacy might and should look like. They started to create the tools they believed the world needed to safeguard data privacy–today, their mission is carried on by developers who value user privacy.

Why Developers Need to Be Familiar With FHE

However, securing the transmission of data is not enough, as many breaches still occur because data isn’t encrypted during processing.

So, in a world where more and more data needs to be shared to deliver the sort of experiences consumers expect, is it inevitable that privacy and security will be compromised as the volume of data exchanges grows? Not necessarily.

Fully homomorphic encryption (FHE) offers a solution, allowing developers to build applications and run services without needing to see or secure the underlying data. This is because FHE enables data to be processed blindly without having to decrypt it at any stage. FHE offers a way for developers to maintain that all-important balancing act between maintaining privacy and offering value to both business and customer.

In FHE, to guarantee a user’s data privacy, all data is encrypted by the user with their own secret key. Users of a particular service, such as an online medical portal, will use a secret key to send their encrypted data to a server where blind processing takes place. The result is also encrypted and sent back, the user again using their secret key to decrypt the information.

What this means is that, because data is encrypted end-to-end, the company providing the service can do so in a way that keeps the same customer experience, even though they cannot see the data that is being shared and sent back. From a security perspective, this is also critical. Governments, attackers and service providers cannot see the exchanged information because they do not possess the key–they also cannot break it, as the encryption used in FHE can resist attempts made even by powerful quantum computers.

Privacy can also be protected during larger-scale data exchanges that underpin collaboration between organizations and nation-states on numerous strategic programs, with each contributor able to add their value knowing that their intellectual property and sensitive information is not compromised.

Looking ahead, if developers can embed FHE into their practices on a broad scale, then a key milestone for privacy is within reach. Rather than being viewed as an objective relating to digital interactions, privacy can be treated as a naturally occurring by-product of every application, piece of software and service that the developer community creates.

June 20, 2023
Revolutionizing DevOps Culture Transformations With AI-Engineered Tools

In my recent article Revolutionizing the Nine Pillars of DevOps with AI-Engineered Tools, I explained that DevOps thrives in a culture of openness, transparency and shared responsibility. It’s about breaking down the silos that can exist between different teams (like development, operations, security and QA) and promoting effective communication and collaboration. AI-powered tools can improve collaboration through smart recommendations, fostering more effective communication and knowledge sharing.

Collaboration and Communication: AI-powered chatbots can facilitate quick and easy communication across teams, enabling faster decision-making and problem-solving. AI-powered project management tools can improve visibility into tasks and dependencies, promoting better coordination among team members.

Continuous Learning and Improvement: AI-based monitoring tools can help teams learn about system performance in real-time, identifying trends and patterns that can inform better decision-making. AI can also help in creating personalized learning experiences, identifying skills gaps and suggesting relevant training resources, promoting a culture of continuous learning.

Shared Responsibility and Ownership: AI can improve visibility into the system’s state, helping all team members understand how their work contributes to overall system performance. This can promote a sense of shared ownership and responsibility. AI can also assist in automating the allocation of tasks based on an individual’s skills and availability, promoting a more equitable distribution of responsibilities.

Automation and Efficiency: AI is pivotal in automating routine tasks, such as testing, deployment and monitoring. This can significantly improve efficiency and allow teams to focus on strategic, high-value tasks. AI can also help automate the detection and resolution of common issues, reducing downtime and improving system reliability.

Feedback and Adaptability: AI-powered analytics tools can provide real-time feedback on system performance, enabling teams to quickly adapt their approach as needed. AI can also help in analyzing customer feedback and identifying key themes and sentiments that can inform product development.

Risk-Taking and Innovation: AI can help simulate the potential impacts of different decisions, allowing teams to take calculated risks. AI can also drive innovation by helping teams identify new opportunities, predict trends and develop more creative solutions.

Roadmap to AI-Assisted DevOps Culture

A practical roadmap for transforming an organization’s DevOps culture using AI-engineered tools may look something like this:

1. Define Goals and Evaluate the Current State: Identify what you want to achieve by integrating AI into your DevOps practices. This could be improving deployment times, reducing errors, increasing productivity and more. Evaluate your current DevOps practices and tools to understand where AI could bring the most value.

2. Identify AI Opportunities and Select Tools: Look for areas where AI can enhance collaboration and communication. This could involve AI-powered chatbots for team communication or project management tools with AI capabilities. Identify opportunities for AI to support continuous learning and improvement. AI-powered analytics and monitoring tools can provide valuable insights for this. Determine where AI can help promote shared responsibility and ownership. AI-enabled visibility tools can assist here, too.

Choose areas for AI-powered automation. This could include tasks like testing, deployment and issue resolution. Find avenues where AI can support feedback and adaptability. Tools that analyze system performance or customer feedback could be helpful here. Pinpoint where AI can assist in risk-taking and innovation. AI-powered simulation or predictive analytics tools could be useful.

3. Implement AI Tools Gradually: Start by integrating AI tools into one or two areas of your DevOps process. Monitor the impact to ensure you’re driving the desired improvements. Gradually expand the use of AI tools to other areas of your DevOps practices.

4. Train Teams on AI Tools: Provide adequate training to your teams so they can use these new AI tools effectively. Encourage a culture of learning and experimentation to help teams become comfortable with AI.

5. Monitor and Adapt: Regularly monitor the impact of these AI tools on your DevOps practices. Are they improving speed, reducing errors, enhancing collaboration, etc.? Be prepared to adapt your approach based on the feedback and results you’re seeing. The integration of AI is a journey, not a one-time event.

6. Continuously Improve: Continually look for new ways that AI can enhance your DevOps practices. AI is a rapidly evolving field, and new opportunities are emerging all the time. Remember that this roadmap is iterative and adaptive. AI integration should be seen as a part of the broader DevOps goal of continuous improvement.

Benefits for Organizations, Teams and Individuals

With the integration of AI-engineered tools into DevOps processes, organizations can expect significant improvements in efficiency, speed and quality. AI automation can drastically reduce manual, repetitive tasks, thereby lowering the chance of errors and freeing up resources for more strategic endeavors. This can lead to cost savings and a better allocation of resources. Additionally, AI can enable faster decision-making and problem-solving, accelerating the software development life cycle and making the organization more competitive. AI can also enhance product quality by providing valuable insights and analytics, enabling continual improvement.

For Teams: AI can facilitate improved collaboration and communication, making workflows more seamless and efficient. AI-powered project management tools can provide better visibility into tasks, dependencies and progress, enabling smoother coordination. AI can also automate routine tasks, freeing up team members to focus on more challenging, high-value work. Additionally, AI can provide real-time feedback and insights, enabling teams to continuously learn and improve their processes. These improvements can lead to higher job satisfaction and productivity.

For Individuals: Individuals stand to gain from AI integration in several ways. AI-powered tools can support skill development by helping individuals learn new technologies and best practices. Real-time feedback and insights can also foster personal improvement. Automation of routine tasks allows individuals to focus more on creative and strategic aspects of their work, leading to a more engaging and satisfying job experience. Furthermore, being part of an AI-driven DevOps environment can open opportunities for individuals to work on cutting-edge technologies and innovative projects, enhancing their career prospects.

Measuring Success

Choosing the right metrics is crucial for measuring the progress of your DevOps culture transformation with AI-engineered tools. Here are some important metrics to consider:

Deployment frequency: This is a measure of how often new features, bug fixes or updates are deployed. An increase in deployment frequency can be a sign that AI tools are improving efficiency.
Lead time for changes: This metric refers to the amount of time it takes from code being committed to it being deployed. AI tools can help to reduce this time by automating testing and deployment processes.
Change failure rate: This is the percentage of changes that result in a failure or that require a rollback or hotfix. AI can help reduce this rate by improving testing accuracy and identifying potential issues earlier in the development process.
Mean-time-to-recovery (MTTR): This is the average time it takes to recover from a failure. AI tools can help to reduce MTTR by quickly identifying the cause of failures and automating the recovery process.
Customer satisfaction: AI can help improve the quality and reliability of the product, leading to increased customer satisfaction. Customer satisfaction can be measured using surveys or net promoter score (NPS).
Efficiency metrics: Look at how much manual, repetitive work has been reduced by automation. This could be measured in terms of man-hours saved.
Learning and development: Monitor the upskilling of your teams to using AI tools and technologies. This could be tracked through training completion rates, skill assessments, etc.
Innovation rate: AI can free up teams to focus on innovation. Measure the number of new ideas or features being developed over time.

Summary

To transform DevOps culture with AI tools, organizations must set clear goals, identify AI opportunities, gradually implement those tools and monitor their impact. Training teams to use AI tools effectively and fostering a culture of continuous learning and improvement will enable this transformation and help DevOps teams thrive. This integration can significantly enhance efficiency, decision-making speed and product quality at an organizational level.

On a team level, AI can streamline collaboration, automate routine tasks and provide real-time insights for continuous process improvement. For individuals, this transformation provides opportunities for skill development, personal growth and more satisfying job experiences. Monitoring progress with metrics like deployment frequency, lead time for changes, change failure rate, mean-time-to-recovery (MTTR), customer satisfaction, efficiency, learning and development and innovation rate ensures the transformation is delivering the expected benefits and contributing to continuous improvement.

June 19, 2023
Four Ways to Modernize Your Enterprise Monoliths

In a perfect world, every application would run like Netflix–by which I mean every application would be cloud-native, microservices-based, containerized and, in all other senses of the word, modern. Unfortunately, not every application can be transformed in these ways. Some of the most important enterprise applications–like those powered by SAP or Oracle–don’t lend themselves to architectural transformations simply because the vendors don’t support that strategy. As much as organizations might wish that they could re-architect legacy apps from the ground up, the reality is that they just can’t.

Fortunately, though, all hope is not lost if you have an enterprise app that you can’t containerize or “microservices-ize.” Even if you can’t “break down your monolith”–to quote the standard advice you’ll find if you read articles about how to modernize legacy apps–there are a variety of practical steps you can take to make legacy, monolithic applications look and feel (in most respects) like modern, cloud-native apps.

Here are four ways to make your enterprise monolithic apps more cloud-friendly, even if they’re not technically cloud-native.

Use Cloud Automation to Modernize Legacy Application Management

Most enterprise apps are compatible with the cloud in the sense that you can host them on cloud-based virtual machine (VM) instances using services like Amazon EC2.

By taking advantage of cloud hosting for enterprise apps, organizations can also leverage cloud automation tools, such as autoscaling policies and rules that automatically start or stop VMs. In this way, it becomes possible to deploy enterprise apps in a highly scalable, automated way. You get something that resembles Kubernetes-based orchestration, except your apps don’t actually run in containers on top of Kubernetes. They’re just monoliths that benefit from cloud automation tools.

Deploy Load Balancers to Optimize Performance

Load balancers, which automatically manage network traffic flowing to and from applications, are another critical tool that organizations can easily leverage when they migrate legacy applications to the cloud.

Although configuring load balancers for enterprise apps hosted in the cloud is not a strict requirement, doing so can substantially improve application performance and reliability because load balancers help to ensure that requests are directed at application instances best able to handle them. They prevent situations where one instance of your application is overwhelmed with traffic while another sits idle.

Again, this is something that platforms like Kubernetes also do for microservices apps. But, as I’ve explained, you don’t actually need your app to run as microservices to take advantage of load balancing. You can do it with monolithic legacy apps, too.

Adopt an Everything-as-Code Strategy

When your app lives in the cloud and is managed by cloud automation tools, it becomes possible to manage most aspects of application operations via code. Specifically, you can:

● Use infrastructure-as-code (IaC) tools to automate infrastructure provisioning and setup.
● Automate application configuration management using code rather than applying configuration changes manually.
● Codify operational processes, such as application updates and backups, instead of relying on manual operations.

Practices like these, which enable a strategy known as everything-as-code, significantly reduce the amount of time and manual effort that engineers spend managing applications. They also provide consistency and minimize the risk of errors due to human oversight. And there’s no reason why you can’t leverage these practices for legacy apps as well as modern ones.

Integrate Legacy Apps With Modern Toolchains

If your enterprise app is hosted on-premises, you probably manage it using tools and processes designed solely for it. But when you move an enterprise app to the cloud, it becomes possible to manage the application using the same integrated toolchain you deploy for other applications and processes.

You can, for example, take advantage of cloud-based monitoring tools to continuously collect data about application performance and generate automated alerts when something is wrong. Likewise, you can regularly create image-based backups of your application.

This toolchain-based operational strategy is another way to streamline enterprise application management, even in situations where you can’t rewrite or containerize the application itself.

Conclusion: Getting More From Legacy Apps

Just because you have a legacy enterprise app that you can’t transform into microservices doesn’t mean you have to settle for legacy management and operational practices. Modern automation tools combined with modern operational strategies like everything-as-code make it possible to achieve an enterprise application management experience that closely parallels that of fully modern, cloud-native apps, regardless of which architecture your app actually uses.

June 15, 2023