I remember the moment I heard about Serverless technology. On a bus back to the hotel at a conference, I overheard a CTO telling one of her developers about this "new" thing called Lambda. She said (and I'm paraphrasing): "so, the code is there, but it's not running anywhere — until you need it, then it appears, executes and disappears again."
I literally (YES, literally) got goosebumps. I had thought containers were cool, but this? O-M-G!!!
That night I had visions of millions of pieces of code just waiting in the wings for its time to be executed. Of course, the reality of today is that Serverless is a big part of modern application strategy, but not executing every workload like one might think.
There are three key reasons for that:
1. Architecting a serverless function into your operating applications isn't (or wasn't) the easiest thing in the world to do.
2. While the idea of serverless workload execution promises minimal cloud operating costs, the reality of serverless platform pricing is that sometimes it might be more.
3. The monitoring and performance management tools relied upon by IT shops around the globe couldn't handle serverless,
Now, you might be thinking "but wait. Many application monitoring tools struggled for years with containers, but that technology took off like a rocket."
And you would be right. That's one of the reasons I asked myself this important question: Can APM tools Manage Serverless Workloads?
And the answer is "No, not really."
No, don't go searching the web for serverless monitoring to look for a lack of functional claims. Every monitoring solution in the world claims support for monitoring serverless platforms (at least one of them).
What I mean by my answer is that the "APM" solutions we've come to love over the last 2 decades can't handle Serverless Functions or deliver the same performance and operational details that they deliver for other architectural constructs — including App Servers, Frameworks, Cloud, even Containers. And the reason is that they're methodologies for collecting performance data simply won't operate with the same characteristics as it would in persistent code.
To fully understand the nuanced differences between running an agent and capturing data from an API as it relates to monitoring, let's look at some of the operational costs of running serverless code.
Let's first look at what I call the Unicorn of Serverless application functionality — a seldomly called stateless functional piece of work — calculating a payment would be a good example. The inputs are the loan amount, the number of payments and the annual interest rate — the outputs are the interest payment and full payment. The function is called seldomly, requires very few resources to run (meaning little setup) and operates statelessly.
The Unicorn function can be loaded onto a serverless platform such as Lambda with zero permanent persistence (saves money). And a cold start doesn't hurt performance, so it can literally open up and shut down when you need it (also saving money). Now that we've established the perfect way to operate a serverless workload from a financial efficiency perspective, let's consider the three prerequisites:
■ Seldomly called — in the realm of efficient development, services that are never called are either deprecated or rolled into other functionality to make storage and operations as efficient as possible. Thus, a meaningful piece of code that is seldomly called is not really a thing anymore.
■ Requires few resources — again, in the realm of meaningful functions, the need for resources (memory, storage, I/O, etc.) is usually directly related to how important a piece of code is. Which maps back to the same decision point as seldomly called — a function that requires few resources is unlikely to operate on its own, instead being part of a shared service with active listeners, triggers, etc.
■ Is stateless — this is perhaps the least likely of scenarios to be present in today's microservice applications. Even plain old informational websites contain state of users — history, cache, setup, preferences, etc. The odds of having any kind of critical application service that doesn't have a personalized aspect to the workload is rare.
That's why the Unicorn Serverless operation is a rarity, and why cost isn't necessarily less anymore. Since (almost) every function requires some level of resources to use and/or a state — or access to state through a known memory location, two things become a concern.
First is performance — if you have to spin up resource libraries every time you want to run your piece of code, that can have a significant overhead, depending on how complex and resource intensive your piece of code is. I'm going to come back to this in a minute or two, so remember how just setting up your libraries can cause a relative performance impact of 50 — 500%.
Given the performance conundrum, the solution is to use functionality in the serverless platforms, like Lambda, to keep a warm pulse of libraries running so that there's no performance impact. This is referred to as a warm start serverless function.
Now, while this may address the performance issue, naturally it begins to detract from our cost savings. It's one thing to only pay for CPU cycles when you need to run the function — quite another when you're still ALWAYS paying for something, just a little less than you normally would.
Organizations use data to fuel their operations, make smart business decisions, improve customer relationships, and much more. Because so much value can be extracted from data its influence is generally positive, but it can also be detrimental to a business experiencing a serious disruption such as a cyberattack, insider threat, or storage platform-specific hack or bug ...
Previously siloed IT teams and technologies are converging as enterprises accelerate their modernization efforts in reaction to COVID-19, according to a study by LogicMonitor ...
You surf the internet, don't you? While all of us are at home due to Covid lock-down and accepting a new reality, the majority of the work is happening online. IT managers are looking for tools that can track the user digital experience. Executives are reading a report from Gartner or Forrester about some of the best networking monitoring solutions available on the market. Project managers are using Microsoft Teams online to communicate and ensure team members are meeting deliverables on time. Remote employees everywhere use OWA to check their office mails. No matter what, you can be quite sure that everyone is using their favorite browser and search engine for connecting online and accomplish tasks ...
With the right solutions, teams can move themselves out of the shadows of error resolution and into the light of innovation. Observability data, drawn from their systems and imbued with context from AI, lets teams automate the issues holding them back. Contextualized data and insights also give them the language to speak to the incremental, product-led approach and the direction to drive key innovations in customer experience improvement. Communicating value becomes a much easier proposition for DevOps practitioners — and they can take their seat at the company table as contributors to value ...
Prediction: Successful organizations will blur (or erase) the line between ITOps and DevOps. DevOps has to coexist with traditional IT operations ... So bring a little DevOps to every aspect of IT operations. You don't even have to call it DevOps ...
The use of unified communications and collaboration (UC&C) solutions has increased since the start of the pandemic, and this increased use has created challenges for IT teams, according to a survey commissioned by NETSCOUT SYSTEMS ...
Cloud-based innovations like microservices, containers and orchestration let developers code better, faster, but the underlying infrastructure becomes dynamic and ephemeral, and service-level interactions are hard to see. It’s a critical evolution, but the rapid change reduces visibility, predictability and control. Hence, observability ...
Companies love data. Aggregating data from multiple sources makes decision-making easier and brings a new depth of the conversation to business meetings. But all of this is at the management level. IT managers and administrators also search for data from multiple sources to ensure that the ecosystem works ...
The cost of poor software quality (CPSQ) in the US in 2020 was approximately $2.08 trillion, according to The Cost of Poor Software Quality In the US: A 2020 Report from the Consortium for Information & Software Quality (CISQ), co-sponsored by Synopsys. This includes poor software quality resulting from software failures, unsuccessful development projects, legacy system problems, technical debt and cybercrime enabled by exploitable weaknesses and vulnerabilities in software ...