devopsy.kinsta.cloud

Category: Blogs

ngrok Previews API Gateway Service to Streamline App Networking

Under an early access program, ngrok today made available an application programming interface (API) gateway that can be consumed as a service.

Rather than having to deploy, maintain, and secure API gateways themselves, application development teams, via a single command or function call, can now invoke a service through which they can route API traffic, authenticate and authorize access, and apply rate-limiting policies using an ngrok policy engine.

ngrok CEO Alan Shreve said this approach also makes it simpler for IT teams to unify ingress management at a time when application networking is becoming more challenging to manage. That approach also reduces friction because instead of being dependent on an IT operations team, it gives developers more direct control over APIs, he added. Today, most access to APIs is granted after developer first create a ticket request in an IT services management (ITSM) platform, noted Shreve.

In addition, the ngrok gateway also streamlines access to APIs spanning multiple clouds and on-premises IT environments in a way that enables organizations to implement a multi-cloud computing strategy, he added. Today, many organizations are locked into a single platform because they are dependent on the API gateway services provided by their cloud service provider, noted Shreve.

Finally, organizations will only need to pay for the API gateway service based on actual usage versus incurring the cost of acquiring a gateway upfront, said Shreve.

Previously, ngrok has been making available software development kits (SDKs) to provide programmable access to its API gateway. The as-a-service option being offered now is the next logical extension of that effort, noted Shreve.

In general, more infrastructure than ever is being consumed as a service, so making available an API gateway service is only the latest example of that larger trend, he added.

Each organization, based on total cost, will naturally need to decide when it makes the most economic sense to consume IT infrastructure as a service; however, as application networking continues to become more challenging to manage at a time when the number of IT professionals with that expertise remains limited. Relying on a service provides a viable alternative for managing what are often hundreds of APIs spanning a distributed computing environment.

It’s not clear yet precisely which teams within an IT organization are assuming responsibility for application networking, but as layer 4 through layer 7 of the networking stack become more programmable, more responsibility for networking can be assumed by DevOps and platform engineering teams. Existing networking teams, meanwhile, continue to manage the physical networking underlays used to route network traffic. Regardless of how application networking evolves, the rigidity that has characterized the delivery of network services is starting to fade away in a way that makes it possible to dynamically invoke networking services as needed.

IT teams must decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications. The goal, however, should be to eliminate as much friction as possible at a time when applications have become more dependent on networking services than ever.

February 15, 2024
Will Generative AI Succeed Where AIOps Failed?

For decades, the tech industry has been enamored with artificial intelligence, the idea that machines can think like humans. Because these machines never get tired — and compute power increases 10x every five years — we expected them to quickly figure out the meaning of life, the universe and everything else. Around 10 years ago, companies such as Moogsoft emerged, claiming that they could make the lives of IT operations teams a whole lot easier by applying AI to the digital exhaust fumes emitted by infrastructure and applications. Blessed by leading analysts, the segment quickly became known as “AIOps.”

The prevailing thought behind AIOps was that patterns in how applications and infrastructure operate could, over time, be determined — and then used to predict when a problem would occur. Even better, maybe problems could even be fixed before anyone noticed. Magic.

Like most magic, though, not everything is as it appears.

Machine learning is like having 1,000 first graders at your disposal. They’re smart enough to be taught to identify a spike in a chart—or a kitten—and alert you when they see one. However, enterprise environments are inherently noisy. If you ask to be notified every time your first graders see a kitten (spike), get ready to receive a lot of notifications. This simple example highlights why ML is great for identifying kittens in consumer search but not so great for identifying problems with enterprise applications.

What makes matters worse is that modern applications change every day, which means that there will be no predictable pattern in their operation. Put another way, the digital exhaust the application emits cannot be used to create a useful model to detect anomalies.

Most AIOps projects became consulting exercises in writing complex alerting rules. Often, they were great at detecting and predicting things you already knew about but singularly useless in helping with “unknown” problems—the problems you’ve never seen before—and the things SREs troubleshoot in distributed applications and struggle with daily.

The Dawn of Generative AI

Just as the sun appeared to be setting on AIOps, we witnessed the dawn of generative AI. AIOps and generative AI both have the acronym ‘AI’ in them, but that’s where the similarity ends. Generative AI uses large language models (LLMs) to better interpret—and respond to—inquiries. The humble chatbot, aka ChatGPT, quickly became the killer app. Powered by LLMs, ChatGPT talked sense most of the time on almost any topic.

Of course, just like with AIOps, it’s easy to jump to magical conclusions regarding the capabilities of this new technology. ‘Why can’t I just train an LLM on my telemetry data and then ask ChatGPT what the problem is?’ That would imply that telemetry not only had the necessary structure—which it doesn’t—but also that LLMs can reason. Which they can’t.

Let’s dial back the expectations from magical to practical.

LLMs are amazing at interpreting natural language requests and returning coherent results. Every product should, by default, use a GPT-based interface to enable users to access help. In addition, most observability tools use a proprietary scripting language. Every product should also provide a “copilot” so users can generate scripts from natural language inputs. The combination of GPT Help and copilots can provide a 50% boost in productivity to new users.

But what about helping users with the troubleshooting process? LLMs are statistical engines. The next word in a sentence is calculated based on prior words generated and what the most likely next word should be. Imagine applying that to incidents instead of sentences. Instead of generating the next word in a sentence, perhaps you could generate the next step in the troubleshooting flow. That would mean SRE teams could benefit from dynamically created runbooks—always up-to-date and based on the latest and greatest insights.

And we could take it one step further. Instead of simply creating a runbook, what about executing the steps in the runbook before the SRE engages in the incident? Imagine coming to an incident and being presented with a custom dashboard for the specific incident that contains all the data necessary to conduct the investigation. That alone saves an hour in most enterprise troubleshooting flows without promising any “magic.”

AIOps promised a deterministic answer to a non-deterministic problem. It just wasn’t possible to analyze terabytes of machine-generated data and accurately predict a problem with an application, let alone determine the root cause. And generative AI won’t do that, either.

But generative AI can go to so many places that AIOps could never. It provides a general-purpose approach that can be applied in many different ways. Generative AI will lower the barrier to using practically any new tooling, making it easier for everyone to perform common tasks and get up to speed on new scripting languages. Heck, you might never have to write a regex or look up an error message ever again! In addition, LLMs can statistically determine the best next step and, therefore, should be able to make troubleshooting flows more repeatable while benefiting from the most current incident knowledge.

Yes, the SRE still plays a huge role. Of course, LLMs can’t answer questions the underlying tooling is incapable of answering. But I’ll still make the bold statement that five years from now, the average MTTR will be half of what it is today.

February 15, 2024
Pilot or Telephone Operator? Forecasts of Software Developer Demise Are Absurd

Stability AI CEO Emad Mostaque recently grabbed headlines with his audacious prediction that “there [will be] no programmers in five years.” While such statements make great social media clickbait, they don’t accurately reflect the reality of creativity’s role in complex software development. Yes, AI will profoundly change the software engineering profession, but those changes will mostly enable inventive and capable developers to reach new heights of innovation. Software development is already being transformed by generative AI. Microsoft’s GitHub Copilot has more than one million paying customers. Some researchers forecast that between 50% and 80% of software engineering job descriptions will involve generative AI within a few years.

For the foreseeable future, generative AI’s principle value will be automating the mundane tasks that take up so much developer time. Copilots will likely replace many frameworks and code exchanges because they’re faster. They’ll dramatically improve auto-completion and spell check. That’s the grunt work of software development that most programmers will be happy to shed.

Generative AI is expected to be applied most often in testing, vulnerability management and writing code, according to an IDC survey of U.S. developers. However, the same survey found that fewer than 10% of developers expect the technology to have value in such creative disciplines as interface design, prototyping or translating user requirements into applications.

Where LLMs Fail

Building enterprise-grade software requires a keen understanding of business concepts and the ability to design novel solutions. That’s where large language models stumble. Trained on a large corpus of existing data, they excel at quickly spitting out what is already known. That can be of great value, but rewording and repetition aren’t the same as creativity.

Generative AI’s main impact on software development will be reducing mundane tasks and giving developers more time to innovate. Automating manual coding may help dent the chronic shortage of software engineers that shows no sign of easing. However, I have not seen any evidence that technology can think outside the box.

Doom and gloom predictions about automation’s impact on the workforce are nothing new. Occasionally they come true. Thanks to automated switching and direct dialing, telephone operator jobs in the U.S. have fallen by more than 95% since the 1950s. Robots continue to reduce the need for humans to do work no one wants to do.

Up the Stack

The more common outcome is for automation to move jobs higher up the value stack.

● E-commerce and customer self-service were expected to doom the retail industry, but total retail employment is expected to grow nearly 8% through 2030, led by services such as home delivery and specialty merchandise.
● About 90% of a commercial airline flight is now fully automated, yet the shortage of pilots is at an all-time high. That job has evolved from flying the plane to overseeing complex systems and being available for rare but critical emergencies.
● Online banking was supposed to kill bank branches, but there are more today than in 2000. Their role has shifted from processing transactions to delivering complex and customized services to the benefit of tellers and customers alike.
● While travel agent employment dropped substantially with the advent of online booking and the end of airline commissions, the industry is growing again, according to the BLS. Many travel agents have thrived by reinventing themselves as experienced consultants and simplifying the complexities of navigating multiple booking sites.
● Healthcare technology has made huge leaps in diagnostics and patient record management, but the need for human judgment, empathy and complex decision-making ensures that the demand for clinicians will remain strong for a long time.

Is the job of a software developer more like a telephone operator or a commercial airline pilot? Any technology executive will tell you the question is absurd. As a founder and CEO, I believe a top-notch full-stack engineer is more valuable than millions of dollars in venture capital. We’ve only scratched the surface of how software can enrich our lives. Automation will free up developers to spend more time on the tasks that make a difference.

February 15, 2024
Veracode Report Shines Spotlight on Massive Application Security Debt

An analysis of more than a million applications published today by Veracode, a provider of a software supply chain security platform, found 42% of applications contained flaws that remained unfixed for longer than a year.

Based on 1,553,022 dynamic analysis scans and 11,429,365 static analysis scans, the report noted that those applications with that level of security debt were found in 71% of the organizations maintaining these applications. Nealy half of organizations (46%) have persistent, high-severity flaws that constitute ‘critical’ security debt. Approximately 63% of applications have flaws in first-party code, while 70% contain flaws in third-party code imported via third-party libraries.

Remediation rates also vary by flaw type. Fixing third-party flaws takes 50% longer, with half the known flaws fixed after 11 months, compared to seven months for first-party flaws.

Collectively, the scan run by Veracode produced 96 million raw static findings, four million raw dynamic findings and 12.2 million raw software composition analysis findings.

Chris Eng, chief research officer for Veracode, said it’s clear too many organizations are kicking application security flaws down the road only to find they don’t have the time to address them properly. Meanwhile, cybercriminal syndicates and nation-states are becoming more adept at exploiting these flaws with each passing day, he added.

In general, there is a lot more focus on software supply chain security in the wake of an executive order issued by the Biden administration that requires federal agencies to identify and remediate security flaws. However, the pace at which enterprise IT organizations are following the lead of the Federal government varies widely. Only a relatively small percentage of the vulnerabilities that exist in applications running in production environments are being exploited, so many enterprise IT teams have yet to prioritize the issue.

However, as more cybercriminals acquire the skills required to discover and exploit those vulnerabilities, it’s only a matter of time before a major application security crisis ensues, noted Eng.

Theoretically, at least, artificial intelligence (AI) should one day soon make it easier to discover and remediate vulnerabilities, but it’s just as likely cybercriminals will use the same capabilities to achieve their own nefarious ends. In fact, it’s largely a race against time before existing application flaws are exploited using AI-based tools and techniques. Application development teams that fix flaws the fastest reduce critical security debt by 75%, from 22% of applications to just over 5%, the Veracode report noted.

Naturally, it’s less costly and simpler to fix security flaws before applications are deployed in a production environment, so the more organizations embrace DevSecOps best practices on the front end, the lower the overall security debt becomes, noted Eng.

It’s not clear whether organizations might decide to replace or consolidate applications to reduce their security debt, but given the overall lack of cybersecurity expertise among application developers, the current level of security debt is likely to continue to rise. The challenge, of course, is that as the security debt rises, the number of developers available to address, unfortunately, remains comparatively constant.

February 14, 2024
IT Professionals Have Mixed Emotions About AI

A survey of 1,213 IT decision-makers working for small-to-medium enterprises (SMEs) in the U.S., United Kingdom and India published today found nearly half (45%) are worried about the impact artificial intelligence (AI) will have on their job.

Conducted by the research firm Propeller Insights on behalf of JumpCloud, a provider of an IT and cybersecurity management platform, the survey also found more than three quarters (76%) agree their organizations should be investing in AI, with 79% viewing AI as a net positive for their organization.

Most respondents also agree their organizations are approaching AI at exactly the right speed (55%), compared to 22% who said their organization is moving too quickly and 19% who said their organization is moving too slowly.

However, a full 62% also noted that AI is outpacing their organization’s ability to protect against threats, the survey finds.

Tom Bridge, a principal product manager for JumpCloud, said while there is no doubt that AI will change roles within organizations, it’s not likely to replace the need for IT administrators. Instead, IT administrators will be able to manage complex IT environments at much higher levels of scale as AI becomes a force multiplier for managing IT. Many of the low-level tasks that conspire to make managing IT tedious, such as generating reports, will become increasingly automated, noted Bridge.

It’s not clear what impact AI will have on IT roles, but it is arriving at a time when IT organizations are being challenged on several fronts. For example, the survey finds that 56% of respondents are more concerned about their organization’s security posture than they were a year ago. Nearly three-quarters (72%) said any cuts to their security budget would increase organizational risk.

More than half (56%) identified security as their biggest IT challenge, followed by new services and application rollouts (45%), increased work burden (44%) and the cost of remote work solutions (42%). Respondents said network attacks were their biggest challenge (40%), followed by software vulnerability exploits (34%) and ransomware (29%). A full 83% also now require multi-factor authentication (MFA), while two-thirds require biometrics (66%) to access some portion of their IT resources. A total of 83% are also still managing passwords.

More than three quarters (76%) also report increased compliance and regulations requirements in their region.

In addition, a full 88% noted increased vendor prices over the last six months, the survey finds. More than a third of respondents need five to 10 applications to manage worker life cycle (37%), but 22% require 11 or more. Three-quarters (75%) said they would prefer a single tool to do their job over several point solutions.

More than three-quarters (76%) rely on a managed service provider (MSP) to manage some portion of their IT environment, with 42% now relying on an MSP to manage their IT environment completely.

Finally, 57% said their organization has experienced layoffs in the last year. In addition to having to offboard those employees, IT professionals will naturally become more uneasy about their own job security.

Arguably, when it comes to managing IT, there is less certainty today than at any time in recent memory. The challenge, as always, is to aggressively embrace automation as much as possible to reduce a level of IT complexity that is rapidly becoming too complex to manage otherwise.

February 14, 2024
Squaring the Circle: How to Make Public APIs Private
APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

Day 2 API Security Solutions and Snowflakes

This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

A Difficult Race to Win

Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

Why Not Avoid the Race?

So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

Zero-Trust API Networking Needs to be Built for APIs

To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

There are usually three reactions to the diagram above:
1. OK, tell me how it works. See below.
2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.
How Zero-Trust API Networking Works

Here are the four pillars of zero-trust API networking:
1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code:
3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.
The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:
- Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
- Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
- Extensibility. Software-only, cloud-native architectures. Preferably open source based.
- Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
- Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
- Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
- Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.
Zero-Trust API Networking

While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.
February 14, 2024
Data Gravity Will Remain an Issue

Things are improving for IT at a rate we haven’t seen since the first wave of container adoption. We have massive automation in the entire SDLC—with AI-based plug-ins for IDEs to help developers write code that is both higher quality and more secure, security deeply integrated into the DevOps toolchain and the unification of testing/security tools across the SDLC. We are once again turning out more code of higher quality faster than we were just a year ago.

And what is finally starting to catch up is data. I love the current iteration of data virtualization technology, where it can be set to move from region to region or cloud to cloud at leisure in the background. At the same time, data that is accessed in the interim can be instantly transferred. I used to cover storage and data, and frankly, this is the dream world.

But it doesn’t change the fact that data location matters. While bulk moving data to its final destination will be useful, separating data from applications that access it is simply adding another weak link in the application infrastructure chain.

This is where the true strength of containers and Kubernetes come in. With Kubernetes, we can put containers with the entirety of our apps into the environment where our data resides. And that means that our application infrastructure is consolidated and that, in a pinch, both application and data can be moved anywhere–because Kubernetes is truly portable (as long as you don’t use customization features of some vendors/platforms anyway).

The environments we currently choose to use for enterprise applications–from mainframe to public cloud and everything in between–all are capable of running containers, and while there are still deployment differences, customizing a bit to move an entire application is far better than rewriting entire apps to target a new host environment. And the amount of retargeting required is constantly going down.

So, decide where you would like to host your solution, use data virtualization to move the datasets there, spin up your apps in Kubernetes at that location and enjoy the fruits of your labors. Mergers, acquisitions, moves from one architecture to another, moving from public cloud vendor A to public cloud vendor B … All made far easier by data and Kubernetes portability.

While people like to call it “cloud,” what we really should be calling it is “portable.” Whichever marketing person decided that cloud included Kubernetes is my sworn enemy, btw. Because the cloud is used without including Kubernetes, so of course, that just confuses the issue. Portable programming is a far better description of data mobility and Kubernetes architecture used in tandem. Doesn’t need a cloud at all.

And we’re headed there for even more productivity. Just pick where to move it and carry on. We do indeed live in pretty cool times, and you all are the ones making it real. Keep up the good work.

Image source: https://vecteezy_businessman-holding-social-planet-showing-networking-skills_1268342.jpg

February 14, 2024
Legit Security Adds Sensors to Detect Usage of Gen AI Tools to Write Code

Legit Security today announced it has added the ability to detect when developers use generative artificial intelligence (AI) tools to write code to its application security posture management (ASPM) platform.

The ASPM platform developed by Legit Security already has discovery capabilities for application secrets, for example, enabled by sensors that are now being extended to include generative AI tools.

Legit Security CTO Liav Caspi said the overall goal is to allow DevSecOps teams to identify who uses these tools to write which types of code. Each DevSecOps team can then decide how stringently to enforce policies to either ban or limit usage of those tools, he added.

There is no doubt that generative AI tools are increasing developer productivity, but the large language models (LLMs) that provide the ability to generate code were trained using examples of code of varying quality collected from across the web. Much of that code either contains known vulnerabilities or is simply inefficient, which can manifest itself in the output surfaced by a generative AI platform.

The Legit Security ASPM platform, in addition to identifying generative AI tools being used in real-time, can also be employed to scan the LLM itself to identify security risks such as prompt injection and insecure output handling. Unfortunately, most cybersecurity teams are unaware of the extent to which application code generated by a machine might be insecure, so it currently falls to leaders of DevSecOps teams to determine what is an acceptable use of these tools. It may be perfectly fine to rely on a generative AI tool to create a script that will be used for an internal-facing application. However, using the same tool to write business logic that will be exposed to the internet may not be especially prudent.

It’s not clear how much of the code finding its way into software builds is being generated by a machine versus a human. In the longer term, the goal is to be able to identify that code by, for example, detecting substantial changes in the way code is normally written by a human developer, said Caspi.

Of course, while an ASPM may detect usage of generative AI tools that are connected to a corporate environment, there are still plenty of opportunities for developers to use these tools offline to create code that can later be added to a build using a code check-in tool. After all, many developers have used various shadow IT tools to write code for decades. Regardless of who or what wrote that code, however, it should still be reviewed.

In the meantime, the overall size of the codebase that DevSecOps teams will need to manage and secure will only exponentially increase as developers become more productive. Hopefully, more AI capabilities will soon be embedded into DevOps platforms to further automate the management of software builds at a time when many DevOps teams were already finding themselves overwhelmed even prior to the rise of generative AI.

February 13, 2024
Akamai Launches Gecko Edge Computing Services

Akamai Technologies today launched an initiative that promises to make it simpler to centrally manage and deploy application workloads on edge computing platforms.

Shawn Michels, vice president for product management for cloud computing Akamai, said a Generalized Edge Compute (Gecko) offering leverages the global points of presence (PoPs) that Akamai uses for its content delivery network (CDN) to now deploy application workload managed via the Linode cloud service the company acquired in 2022.

At the core of this offering is a set of virtual machines that enable a full stack of application software to be deployed in an edge computing environment to eliminate latency that would otherwise be encountered when transferring data to a cloud computing environment. The ultimate goal is to provide IT organizations with a federated set of services they can employ to process data where it makes the most sense based on performance requirements, said Michels.

For example, applications infused with artificial intelligence (AI) will need to be able to invoke enough compute resources to run inference engines at the edge, while other less compute-intensive application workloads are best deployed in cloud computing environments, he noted.

Michels added that rather than locking IT teams into a specific architecture, Akamai is committing to meeting IT organizations where they are, including adding support for containers running on Kubernetes clusters in its PoPs later this year.

Akamai has more than 4,100 points of presence around the globe. With the acquisition of Linode, Akamai added a set of cloud computing services to compete directly against hyperscalers such as Amazon Web Services (AWS), Microsoft and Google by making cloud services available at a lower cost at a time when more organizations than ever are concerned about the total cost of IT.

In its first phase of Gecko, Akamai will provide access to virtual machines in 100 locations by the end of the year. Akamai has already deployed Gecko servers in Hong Kong SAR; Kuala Lumpur, Malaysia; Querétaro, Mexico; and Johannesburg, South Africa, as well as in cities without a concentrated hyperscaler presence, including Bogotá, Colombia; Denver, Colorado; Houston, Texas; Hamburg, Germany; and Marseille, France. Deployment of a tenth Gecko region this quarter is planned for Santiago, Chile. Akamai is committing to adding hundreds of cities to its global cloud computing footprint over the next several years.

In the longer term, Akamai also plans to add automated workload orchestration to make it easier for developers to build applications across hundreds of distributed locations.

More workloads than ever are being deployed at the network edge as IT teams look to deploy software closer to the point where data is being created and consumed. That will require extending the reach of existing DevOps workflows to edge computing environments that will be based on everything from x86 and Arm processors to graphical processor units (GPUs).

The challenge, as always, will be finding a way to effectively manage those workloads when the IT teams responsible for them are often physically located thousands of miles away.

February 13, 2024
The Practicalities of Open Sourcing

I’ve been deeply immersed in the world of developer products for the past decade, and let me tell you, I’ve been quite the open source enthusiast. Over the years, I’ve had the pleasure (and occasional pain) of shepherding open source projects of all shapes and sizes. It’s almost become a rite of passage in some teams – the moment when your APIs and libraries step into the spotlight. After all, customers want to know what kind of software is going into their code concoctions. But, let’s be real, I’ve also witnessed open source used as a bit of a smoke-and-mirrors exercise. So, if you’re contemplating the daring act of open sourcing your projects, here are some things to know before you set out.

Manage Your Expectations of External Contributions

If I had a penny for every open source manager disappointed by unrealistically high hopes of a flood of external contributions, I’d have enough pennies to… well, still not meet those expectations. The truth is that the majority of open source projects never witness a bustling community of external code contributors. Just because your software is popular doesn’t guarantee open source success. Open source is like nurturing a garden; it takes time and effort to grow. Building a community involves shaping your APIs, fine-tuning functionality, defining boundaries and managing expectations. Expecting an avalanche of external contributions in the early days is a recipe for disappointment.

OSS can be Intimidating

While developers generally relish the idea of sharing their work with the world, I’ve stumbled upon situations where junior engineers were a tad shy about coding in the public eye. In some cases, we’ve had to delay open sourcing because engineers wanted to tidy up their work before unveiling it to the world. Especially if your team is a mix of early-career engineers, it might be easier for senior team members to offer coaching and conduct code reviews in a more private setting without the intimidating public glare.

Issue Triage and the Support Price Tag

In theory, maintaining a public issue tracker is distinct from open sourcing the code itself. In practice, these two are closely linked. Opening up your product’s priorities to the public means putting them on display alongside real interactions and feedback from customers. This doubles the importance of being responsive to customer issues, efficiently triaging them, and setting the right external expectations. For successful open source projects, this is a genuine labor of love.

The Need for a Private Mirror

There comes a time when you need to work on something in private, perhaps in preparation for a grand launch event. Unfortunately, last time I checked, GitHub doesn’t offer private branches. You might find yourself wrestling with the challenge of setting up a private mirror. What happens when you’re juggling a significant launch on an internal mirror while simultaneously managing customer bug fixes on the open source repository? Mirrors are like trying to keep two squirrels synchronized – challenging.

Saying Goodbye to Obscurity

Some software on the internet relies on obscurity for its security. Open sourcing it would be like sending hackers an engraved invitation to a party they don’t need directions to.

Unfriendly Dependencies

If your project is tangled up with third-party libraries sporting licenses that are less open source-friendly than a cactus in a desert, you’re in for a headache. I sincerely hope you don’t run into this, as unfriendly licenses often come hand in hand with unfriendly people.

Navigating the Ecosystem: Dealing With Dependency Upgrades

Open source codebases often face a common challenge – the relentless pressure to keep dependencies up to date. This is especially true for libraries and APIs embedded in customer applications, where managing transitive dependencies and supporting older versions can be a delicate balancing act.

Teams typically adopt one of two approaches. Some isolate these dependencies in a separate namespace to avoid conflicts, while others enforce a policy to always use the latest versions. Regardless of the chosen method, open source projects frequently encounter external contributions aimed at upgrading dependencies. Handling such contributions publicly, and sometimes declining them, can be a tricky task.

Maintainers must navigate this terrain diplomatically, explaining that the proposed change might not be suitable for all users by paraphrasing, “You’re not our only customer, and this could affect many others.” This balancing act showcases the challenges of maintaining open source projects in a dynamic ecosystem.

Unexpected Benefits

Now, let’s not forget the unexpected perks I’ve stumbled upon during my open source adventures. After all, I’ve done enough complaining.

● Modernization: Open sourcing often nudges you to modernize your build and deployment pipelines because, frankly, it’s easier to get them right than to get them wrong.

● Privacy and security: Open sourcing can make addressing questions about privacy and security a breeze. In an era of regulatory crescendo, it’s your golden ticket to showcasing your data-handling ballet. It’s like saying, “Hey, world, check out our moves!”

● Building trust with customers: I’ve found some outstanding team members through successful open source projects.

● Trust in open standards and code: Organizations are increasingly placing their trust in open source software. Your larger customers might care about this more than you’d imagine.

And that’s a wrap, folks. Best of luck with your open source journey!

February 13, 2024