Forem: Michael Bogan

When AI Agents Get It Wrong: The Accountability Crisis in Multi-Agent Systems

Michael Bogan — Wed, 18 Mar 2026 14:57:43 +0000

In the world of security and DevOps, AI agents are being pushed from demos into production quickly. They triage security alerts, coordinate incident response, provision infrastructure, and decide which remediation playbooks to run.

When it all works, everyone is happy. It’s a force multiplier. But when an AI agent fails … who do you blame?

It can be hard to tell who made the call, why it happened, or what evidence exists to explain it. This is even more difficult in multi-agent systems, where responsibility is distributed across models, tools, orchestrators, and human operators. This distribution is powerful, but it also creates an accountability gap that most teams aren’t prepared for.

This is not a theoretical issue. Regulators and standards bodies are converging on real expectations for governance, traceability, and auditability. The NIST AI Risk Management Framework's GOVERN and MAP functions explicitly call for documented roles, risk ownership, and decision provenance for AI systems. The EU AI Act goes further: systems that affect safety or critical infrastructure are classified as high-risk, triggering mandatory requirements for logging, human oversight, and traceability.

These signals mean one thing: accountability can no longer be optional or implicit.

Accountability must be designed into how agentic systems make decisions and how those decisions are recorded and governed.

The point of this post is practical, not academic. If you’re building multi-agent systems in security, DevOps, or observability, you need a clear answer to three questions:

What can go wrong?
How will you know?
Who is accountable when it does?

The good news is that you can make these systems trustworthy without slowing them down. The key is to treat accountability as a product feature, not a compliance afterthought. And you probably already have the tools (hint: it’s your analytics platform) to do just that.

The Accountability Gap

Single-agent systems are already complex, but they at least have a central decision point. Multi-agent systems take it a step further, distributing decisions across multiple components.

One agent classifies the alert, another correlates with telemetry, a third chooses the response.

If the output is wrong, there may be no obvious root cause. Was it the classification prompt? The tool that provided stale data? The orchestrator that weighted the wrong agent? Or a handoff that silently dropped a warning? When your system looks like a team, it can also fail like one, with responsibility spread across roles.

This is where the accountability gap shows up in real teams. Ask a group of engineers, security analysts, and platform owners who is responsible when an agent misses an incident. You’ll get a mix of answers: the model team, the product team, the on-call team, or the vendor.

At the end of the day, you must be able to assign accountability in order to fix problems and improve the system. This means moving from "the algorithm did it" to named responsibility and documented evidence.

In other words, if an agent makes a call that leads to a bad outcome, there must be an identifiable person, team, or role that can explain the decision, the data that informed it, and the controls that were in place.

This shift is already happening inside compliance programs and audit expectations, and it’s coming to product and engineering teams next.

One solution is using your observability and analytics program as an accountability program. When agent decisions are logged with the same rigor as infrastructure events, you can connect outcomes to evidence. You know what was decided and why. That makes accountability real rather than rhetorical.

Of course, that raises the question: how do disagreements in multi-agent systems work? Let's look at that next.

Multi-Agent Conflict Resolution

When multiple agents evaluate the same input (which is common for high-stakes decisions), disagreements are inevitable. You are literally running multiple models, each with partial context and different heuristics. The important question is: how does the system handle these disagreements and whether it makes the conflicts visible to your analytics.

Voting
The simplest pattern is voting. In voting, each agent returns a decision and the majority wins. This is fast, but it can be brittle. A correlated error across two agents can drown out the one that is correct. It’s also easy to hide the disagreement, which is the worst possible choice from an accountability perspective.

The disagreement itself is a risk signal. You want it recorded and reviewable later.

Here's what a recorded voting disagreement might look like in practice:

{
    "timestamp": "2025-06-14T03:22:19.007Z",
    "trace_id": "abc-7f3a-...",
    "event": "agent_vote_conflict",
    "alert_id": "SEC-90471",
    "votes": [
      {"agent": "classifier-v2", "decision": "suppress", "confidence": 0.72},
      {"agent": "correlation-agent", "decision": "suppress", "confidence": 0.65},
      {"agent": "anomaly-detector", "decision": "escalate", "confidence": 0.88}
    ],
    "resolution": "majority_vote",
    "outcome": "suppress",
    "dissenting_agents": ["anomaly-detector"],
    "dissent_confidence_gap": 0.19
  }

Notice the dissent_confidence_gap. The dissenting agent was actually the most confident.

Now it’s time to take advantage of our analytics platform. For this (and other examples in this article), we’ll use Sumo Logic, a cloud analytics platform. In Sumo Logic we set up a scheduled search to alert when a high-confidence agent is outvoted:

_sourceCategory=agents | json "event", "dissent_confidence_gap" | where event = "agent_vote_conflict" and
  dissent_confidence_gap > 0.15

Now the silent disagreement is a flag you can review before it becomes an incident.

Negotiation
Negotiation-based systems are more flexible. One agent can propose a remediation, another bids to handle it, and the orchestrator chooses.

This approach is based on early multi-agent research, but in production it should be grounded in clear criteria and recorded choices. If a lower-cost or lower-confidence agent is chosen as the winner, that decision needs to be visible later in an incident review.

Mediator
Mediator or arbitrator agents resolve conflicts when other agents disagree. This can work well, but it changes the accountability picture. The mediator becomes a critical decision point, and its reasoning must be traceable. Usually, the mediator is a more advanced model.

Importantly, you need to know why the mediator made the decision it made. If you can’t explain why the arbitrator overruled a security warning, you haven't actually improved safety. You’ve just moved the black box.

In practice, you don’t need academic consensus protocols to get this right. You need simple rules: define how disagreement is detected, set thresholds for escalation, and make the disagreement and resolution visible in logs.

That last part is crucial. Without it, you are left with a clean output but no evidence or audit trail.

Here is a diagram that demonstrates all the methods:

Let's consider how to turn these ideas into product-level controls.

Process Frameworks for Production

The most important move you can make is to treat agent workflows like production systems, not experiments. That means clear ownership, controlled changes, and reliable telemetry.

Governance
Start with governance. An AI Quality Control function does not have to be a new department. It can be a lightweight set of responsibilities: who approves changes to prompts and thresholds, who reviews the impact of those changes, and who owns the system-level outcomes. If the system is making high-stakes decisions, those roles need to be explicit.

Decision Record
Next, define a decision record. For each agent action, capture the inputs, tool calls, outputs, confidence, and any thresholds or policies applied. A readable summary is useful for humans, but it’s not enough. You need the raw evidence. This is where analytics platforms are extremely useful.

Here's what a structured decision record looks like when ingested into Sumo Logic:

 {
    "timestamp": "2025-06-14T03:22:18.441Z",
    "trace_id": "abc-7f3a-...",
    "agent_id": "triage-classifier-v2",
    "action": "classify_alert",
    "inputs": {
      "alert_id": "SEC-90471",
      "source": "waf-east-1",
      "raw_severity": "medium"
    },
    "tool_calls": [
      {"tool": "lookup_ioc_feed", "result": "no_match", "latency_ms": 340},
      {"tool": "get_recent_alerts", "result": "3 similar in 24h", "latency_ms": 122}
    ],
    "output": {"classification": "low", "confidence": 0.72},
    "threshold_applied": "suppress_below_0.80",
    "escalated": false,
    "model": "gpt-5.2",
    "prompt_version": "classifier-v2.4.1"
  }

When every agent decision emits a record like this, you can correlate agent actions with infrastructure events. A query as simple as:

_sourceCategory=agents | json "output.confidence" as confidence, "agent_id" | where confidence < 0.80 | count by agent_id

surfaces every low-confidence decision across your fleet, creating a searchable evidence trail.

Instrument Everything
Finally, instrument everything. Observability is the bridge between "we think" and "we know." If your agents call tools, read from data stores, and write outputs, those actions should be traced end to end. OpenTelemetry is a practical, vendor-neutral way to make that happen across services and tools.

In practice, wrapping an agent decision in an OpenTelemetry span takes very little code:

from opentelemetry import trace

  tracer = trace.get_tracer("agent.triage")

  async def classify_alert(alert):
      with tracer.start_as_current_span("classify_alert") as span:
          span.set_attribute("agent.id", "triage-classifier-v2")
          span.set_attribute("agent.prompt_version", "classifier-v2.4.1")
          span.set_attribute("alert.id", alert["id"])

          result = await run_classification(alert)

          span.set_attribute("agent.confidence", result["confidence"])
          span.set_attribute("agent.decision", result["classification"])
          span.set_attribute("agent.escalated", result["confidence"] >= 0.80)
          return result

Each agent in the pipeline emits its own span under the same trace, so you get a full causal chain from alert ingestion to final decision. Then, using Sumo Logic's OpenTelemetry integration, we ingest these traces directly, letting you query across agent spans, tool calls, and infrastructure events in one place.

Next let's look at a hypothetical, but very plausible, failure of process that happens when observability is weak.

A realistic failure story (and how it happens)

Imagine a security operations team running a multi-agent triage system. One agent classifies incoming alerts, a second agent correlates with recent logs, and a third decides whether to open a ticket.

A genuine intrusion alert arrives. The classification agent labels it as low priority. The correlation agent flags a weak anomaly but sees no matching indicator. The decision agent chooses to suppress the alert. Hours later, a breach is discovered.

When the incident review begins, the team tries to answer a simple question: why was the alert suppressed?

The logs show the final decision but not the intermediate reasoning. It turns out the correlation tool was operating on stale data due to a delayed pipeline. The classification prompt had been tuned the prior week to reduce noise. The decision agent gave extra weight to the classification agent because it was historically more accurate. The system made a rational choice given its inputs. The problem is that no one can reproduce those inputs or see the disagreement that occurred.

This is the core accountability gap. The organization does not just lack a fix. It lacks a coherent explanation. And without an explanation, it can neither learn nor prove that the system is safe enough to keep in production. That is why analytics and evidence are not nice-to-haves. They are the difference between a system you can trust and one you cannot.

Now imagine the same scenario, but instrumented. The team opens Sumo Logic and runs:

_sourceCategory=agents "abc-7f3a"
    | json "agent_id", "action", "tool_calls", "output.confidence", "inputs", "trace_id"
    | where trace_id matches "abc-7f3a-*"
    | sort by _messageTime asc

They immediately see the full decision chain:

The classifier's 0.72 confidence
The correlation agent's lookup_ioc_feed call returned no_match against data that was 6 hours stale, and the decision agent's suppression.
They can see that the classifier prompt was updated two days ago by checking prompt_version. And they can see the decision agent suppressed the alert despite the anomaly detector's 0.88 confidence flag, because the classifier's low-priority label and the correlation agent's no-match result both pointed toward suppression.

Most importantly, they can set a rule so it never happens the same way again: alert when tool_calls reference a data source with freshness older than a threshold, or when a high-confidence dissent is overridden on a security-tagged alert.

The hours-long investigation now just takes minutes.

Why Does This Matter?

Business stakeholders, developers and operators care about operational outcomes: fewer false positives, faster triage, and better reliability. Multi-agent systems can deliver those outcomes, but only if the team can trust them.

And trust is not a feeling…or at least it shouldn't be. It’s a property of the system. It comes from being able to answer questions like: What did the agent see? What tools did it call? What did it ignore? Why was that alert suppressed? Who changed the thresholds last week?

This is exactly where observability helps. Your observability and analytics platform probably already collects and correlates logs and metrics at scale. The opportunity is to extend that same rigor to agentic workflows: treat agent decisions as first-class telemetry, and connect them to the infrastructure and security signals they depend on. When you do that, you can move from a black-box system to a transparent one, without sacrificing speed.

Conclusion

Multi-agent systems will become a standard part of modern operations. The teams that win with them will be the teams that treat accountability as a feature, not a burden. They will know who owns what, they will be able to trace decisions, and they will have the evidence to explain outcomes when things go wrong including the complete trajectory of every agent and cross-agent communication. That is what trust looks like, and it is what regulators, customers, and internal stakeholders are looking for.

If you are already investing in deep observability, you have most of the building blocks. The next step is to apply them to agentic systems. When AI agents get it wrong, the most important thing is not that they were wrong. It is whether you can prove what happened, learn from it, and show that your system is accountable. This also opens the door for quick improvement, so the system doesn't repeat past mistakes.

Yes! I Can Finally Run My .NET Application on Heroku!

Michael Bogan — Wed, 19 Feb 2025 19:18:36 +0000

Heroku now officially supports .NET!

.NET developers now have access to the officially supported buildpack for .NET, which means you can now deploy your .NET apps onto Heroku with just one command: git push heroku main. 🤯 Gone are the days of searching for Dockerfiles or community buildpacks. With official support, .NET developers can now run any .NET application (version 8.0 and higher) on the Heroku platform.

Being on the platform means you also get:

Simple, low friction deployment
Scaling and service management
Access to the add-on ecosystem
Security and governance features for enterprise use

Intrigued? Let’s talk about what this means for .NET developers.

Why This Matters for .NET Developers

In my experience, running an app on Heroku is pretty easy. But deploying .NET apps was an exception. You could deploy on Heroku, but there wasn’t official support. One option was to wrap your app in a Docker container. This meant creating a Dockerfile and dealing with all the maintenance that comes along with that approach. Alternatively, you could find a third-party buildpack; but that introduced another dependency into your deployment process, and you’d lose time trying to figure out which community buildpack was the right one for you.

Needing to use these workarounds was unfortunate, as Heroku’s seamless deployment is supposed to make it easy to create and prototype new apps. Now, with official buildpack support, the deployment experience for .NET developers is smoother and more reliable.

Key Benefits of .NET on Heroku

The benefits of the new update center around simplicity and scalability. It all begins with simple deployment. Just one git command… and your deployment begins. No need to start another workflow or log into another site every time; just push your code from the command line, and Heroku takes care of the rest.

Heroku’s official .NET support currently includes C#, Visual Basic, and F# projects for .NET and ASP.NET Core frameworks (version 8.0 and higher). This means that a wide variety of .NET projects are now officially supported. Want to deploy a Blazor app alongside your ASP.NET REST API? You can do that now.

Coming into the platform also means you can scale as your app grows. If you need to add another service using a different language, you can deploy that service just as easily as your original app. Or you can easily scale your dynos to match peak load requirements. This scaling extends to Heroku’s ecosystem of add-ons, making it easy for you to add value to your application with supporting services while keeping you and your team focused on your core application logic.

In addition to simple application deployment, the platform also supports more advanced CI/CD and DevOps needs. With Heroku Pipelines, you have multiple deployment environment support options and can set up review apps so code reviewers can access a live version of your app for each pull request. And all of this integrates tightly with GitHub, giving you automatic deployment triggers to streamline your dev flow.

Getting Started

Let’s do a quick walk-through on how to get started. In addition to your application and Git, you will also need the Heroku CLI installed on your local machine. Initialize the CLI with the heroku login command. This will take you to a browser to log into your Heroku account:

Once you’re logged in, navigate to your .NET application folder. In that folder, run the following commands:

~/project$ heroku create
~/project$ heroku buildpacks:add heroku/dotnet

Now, you’re ready to push your app! You just need one command to go live:

~/project$ git push heroku main

That’s it! For simpler .NET applications, this is all you need. Your application is now live at the app URL provided in the response to your heroku create command. To see it again, you can always use heroku info. Or, you can run heroku open to launch your browser at your app URL.

If you can’t find the URL, log in to the Heroku Dashboard. Find your app and click on Open app. You’ll be redirected to your app URL.

If you have a more complex application or one with multiple parts, you will need to define a Procfile, which will tell Heroku how to start up your application. Don’t be intimidated! Many Procfiles are just a couple lines. For more in-depth information, check out the Getting Started on Heroku with .NET guide.

Now we’ve got another question to tackle…

Who Should Care?

The arrival of .NET on Heroku is relevant to anyone who wants to deploy scalable .NET services and applications seamlessly.

For solo devs and startups, the platform’s low friction and scaling takes away the burden of deployment and hosting. This allows small teams to focus on building out their core application logic. These teams are also not restricted by their app’s architecture, as Heroku supports both large single-service applications as well as distributed microservice apps.

Enterprise teams are poised to benefit from this as well. .NET has historically found much of its adoption in the enterprise, and the addition of official support for .NET to Heroku means that these teams can now combine their .NET experience with the ease of deploying to the Heroku platform. Heroku’s low friction enables rapid prototyping of new applications, and Dyno Formations make it easier to manage and scale a microservice architecture. Additionally, you can get governance through Heroku Enterprise, enabling the security and controls that larger enterprises require.

Finally, .NET enthusiasts from all backgrounds and skill levels can now benefit from this new platform addition. By going with a modern PaaS, you can play around with apps and projects of all sizes, hassle-free.

Wrap-up

That’s a brief introduction to official .NET support on Heroku! It’s now easier than ever to deploy .NET applications of all sizes to Heroku. What are you going to build and deploy first? Let me know in the comments!

8 Ways AI Can Maximize the Value of Logs

Michael Bogan — Wed, 17 Jul 2024 12:21:47 +0000

Logging is essential for successful DevSecOps teams. Logs are filled with the information needed to monitor and understand systems. Tracking down a defect? Trying to understand a sudden burst in questionable logins from a new region? Need to figure out why an app is crawling? Logs are that single source of truth for understanding what’s really happening.

But there’s a problem that comes along with logs: the sheer amount of data. The information logged by services and applications just keeps on growing. And growing. It doesn’t take long for it to become more—much more—than can be managed. The data becomes overwhelming. Alert fatigue sets in.

Data keeps growing. Human resources can’t.

But there’s hope on the horizon. Innovations in AI have revolutionized the process of continuous log monitoring. AI algorithms can analyze and detect patterns within vast datasets, translate raw logs into actionable insights, and proactively alert teams to problems—all at a scale and at higher precision to assist humans.

Let’s look at 8 ways that AI can maximize the value of logs.

1: Handling massive amounts of data

First, the most obvious. Cloud-native environments, with their dozens (or hundreds) of distributed components, emit a massive volume of log data. In turn, this data requires high levels of expertise to sift through and analyze it all.

But most organizations already face a shortage of people with the skills needed to tease out the insights from this data. Companies could train more people—but training is slow. And the growing complexity of the data tends to outpace any new skills.

Here is where AI shines: It’s a scalable way to handle log data, no matter the volume and no matter the time. Humans need breaks; they clock out for the day, get sick, take PTO, and play Galaga when bosses aren’t looking. But log data still arrives in massive volumes, regardless of the time of the day or day of the week. An AI-based system with analysis, detection, and alerting is always on.

2: Automated security and access control

When dealing with logs, it’s important to protect any sensitive user information and ensure that the data is only accessible to authorized team members. SecOps managers often implement fine-grained access control to ensure that the approved team members have access to (and only to) the data or metrics intended for use.

AI systems can automatically identify and redact sensitive information—such as personal identifiers, financial details, or confidential business information—from log data before it's accessed by humans. Or, as part of automated preprocessing, AI can de-identify or mask sensitive parts of data.

3: Collating data from disparate sources

Merging data from various sources is a complex task. But it’s essential for effective security and operations. When logs are properly aggregated and correlated, the resulting data and metrics can give the context needed for better visibility and better troubleshooting.

But this is a menial and time-consuming task … which makes it perfect for AI. AI can automatically gather information from various sources and identify patterns within the data, making its analysis easier.

AI correlates data from different sources far more efficiently than a human. Modern log analytics tools leverage AI to gather log data from cloud services and on-premises environments. Log analysis and issue resolution become proactive, preventing negative impacts on the health of applications and systems.

4: Transforming raw log data

Organizations depend on skilled professionals to handle and analyze log data, yet they often face overwhelming resource constraints. This is where AI can contribute significantly, by automating repetitive tasks and enhancing human capabilities.

Before analysis, log data often required cleaning and preprocessing to remove errors, duplicates, or irrelevant information. AI can automate this process, ensuring the accuracy and standardization of all the data. AI can also organize log data into clusters based on similarities or classify them into predefined categories. This helps manage data more efficiently, making it easier for humans to understand and act upon the insights derived.

5: Analyzing log data

A clear use case for AI within a DevSecOps strategy is the automation of repetitive and time-consuming tasks—such as data cleaning, feature selection, and model training. With AI taking on these tasks, developers can focus on other tasks.

AI can sift through a mountain of data to spot duplication and anomalies—like subtle signs of a cyberattack or unusual traffic patterns—that might easily slip past human scrutiny. This yields enhanced security and operational insights.

It’s more than just about handling the volume; AI is adept at detecting patterns that are too complex or too faint for the human eye to catch. For example, let’s consider logging and monitoring for a network to catch signs of data exfiltration. This kind of anomaly might manifest as an unusually high volume of data being sent to an unfamiliar external IP address during off-hours; that’s a pattern that might not immediately raise flags for a human amid thousands of legitimate data transfers happening every day.

On the other hand, an AI-based system that’s trained on vast datasets of normal and malicious network behavior can identify this subtle pattern by correlating different indicators:

The timing of the data transfer
The volume of data
The destination IP address
The type of data being transferred

For a human, recognizing such a complex pattern requires painstaking analysis and might be missed entirely due to the sheer volume of log data. But an AI system can continuously monitor for these patterns across the entire network, detecting potential threats with precision and speed that far surpasses human capability.

6: Reducing alert fatigue

Traditional infrastructure and service monitoring solutions are notoriously noisy, often generating alerts for events that don’t signify a genuine threat. Excessive unactionable alerts lead to alert fatigue.

AI-based alerting intelligently filters alerts and reduces the noise, ensuring that the alerts generated are relevant and actionable. For example, traditional monitoring can’t adjust for seasonality—so a crossed threshold in the middle of a high-season weekday afternoon gets as much attention as one in the middle of the night during what should be a slow week. AI-based alerting uses historical data to continually train its models, factoring seasonality into its baselines. The result is fewer false positives and no more alert fatigue.

Of course, organizations using AI-driven alerting need to rigorously test results in order to tune specificity and sensitivity. This ensures that critical events are captured effectively.

7: Proactive monitoring

Given the large amounts of data an organization generates, teams often struggle to monitor all the organization's resources proactively.

AI is well-equipped to address this issue at scale. By continuously monitoring and aggregating logs from across entire environments, an AI-based tool can identify anomalies before they become widespread, allowing teams to detect potential threats in their initial stages.

For example, the threat detection and investigation from Sumo Logic provides the visibility to address advanced threats before they affect operations. AI features such as this enable real-time monitoring, alerting, and data analysis across security tools, cloud infrastructures, and SaaS applications. This enables a DevSecOps team to investigate and respond to cyber threats swiftly.

8: Efficient incident response

AI-driven alerting improves incident response by facilitating automatic resource allocation and gathering contextual information about an incident. This helps identify potential security threats faster, which in turn helps organizations respond more quickly.

When AI-powered logging and observability platforms provide automated remediation features, teams can connect the dots: from continuously monitored logs to incident detection to remediation playbooks. Automated playbook execution means near-immediate response to an incident, whether that’s eliminating the root cause or alerting an engineer to begin an investigation.

Remember, with every delay in responding to a security incident, the window for impact widens. Minimizing that delay with AI directly minimizes the impact of an incident.

Privacy concerns related to AI adoption

One last note: as we’ve seen, AI shows great promise as a tool for improving logging. But remember that it’s still an emerging technology.

As a recent GitLab report makes clear, there are serious privacy concerns around AI adoption. While 83% of the teams surveyed said implementing AI in their development process was essential, 79% said they were highly concerned about privacy and IP when dealing with AI. But in many business contexts, AI tools need access to that private data for analysis.

So take advantage of AI, but be aware and guard against any privacy concerns.

Drowning in log data? AI is here to help.

Logs are crucial. They’re a rich source of data for monitoring applications and infrastructure. But the multiple data sources and volume of log data—along with the sensitivity of some of that data in the logs—lead to some big challenges in managing log data, security, and privacy.

AI is here to help. Modern log management and SIEM solutions are leveraging AI to automate analysis, enhance monitoring, and improve incident response. AI is making DevSecOps more efficient. And as AI solutions evolve, their role in log analysis will only grow, offering smarter, faster insights into logs.

5 Simple Steps to Get Your Test Suite Running in Heroku CI

Michael Bogan — Wed, 26 Jun 2024 13:27:49 +0000

So, I’ve always thought about Heroku as just a place to run my code. They have a CLI. I can connect it to my GitHub repo, push my code to a Heroku remote, and bam… it’s deployed. No fuss. No mess.

But I had always run my test suite… somewhere else: locally, or with CircleCI, or in GitHub Actions. How did I not know that Heroku has CI capabilities? You mean I can run my tests there? Where have I been for the last few years?

So that’s why I didn’t know about Heroku CI…

CI is pretty awesome. You can build, test, and integrate new code changes. You get fast feedback on those code changes so that you can identify and fix issues early. Ultimately, you deliver higher-quality software.

By doing it in Heroku, I get my test suite running in an environment much closer to my staging and production deployments. And if I piece together a pipeline, I can automate the progression from passing tests to a staging deployment and then promote that staged build to production.

So, how do we get our application test suite up and running in Heroku CI? It will take you 5 steps:

Write your tests
Deploy your Heroku app
Push your code to Heroku
Create a Heroku Pipeline to use Heroku CI
Run your tests with Heroku CI

We’ll walk through these steps by testing a simple Python application. If you want to follow along, you can clone my GitHub repo.

Our python app: is it prime?

We’ve built an API in Python that listens for GET requests on a single endpoint: /prime/{number}. It expects a number as a path parameter and then returns true or false based on whether that number is a prime number. Pretty simple.

We have a modularized function in is_prime.py:

def is_prime(num):
    if num <= 1:
        return False
    if num <= 3:
        return True
    if num % 2 == 0 or num % 3 == 0:
        return False
    i = 5
    while i * i <= num:
        if num % i == 0 or num % (i + 2) == 0:
            return False
        i += 6
    return True

Then, our main.py file looks like this:

from fastapi import FastAPI, HTTPException
from is_prime import is_prime

app = FastAPI()

# Route to check if a number is a prime number
@app.get("/prime/{number}")
def check_if_prime(number: int):
    return is_prime(number)
    raise HTTPException(status_code=400, detail="Input invalid")

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="localhost", port=8000)

That’s all there is to it. We can start our API locally (python main.py) and send some requests to try it out:

~$ curl http://localhost:8000/prime/91
false

~$ curl http://localhost:8000/prime/97
true

That looks pretty good. But we’d feel better with a unit test for the is_prime function. Let’s get to it.

Step #1: Write your tests

With pytest added to our Python dependencies, we’ll write a file called test_is_prime.py and put it in a subfolder called tests. We have a set of numbers that we’ll test to make sure our function determines correctly if they are prime or not. Here’s our test file:

from is_prime import is_prime

def test_1_is_not_prime():
    assert not is_prime(1)

def test_2_is_prime():
    assert is_prime(2)

def test_3_is_prime():
    assert is_prime(3)

def test_4_is_not_prime():
    assert not is_prime(4)

def test_5_is_prime():
    assert is_prime(5)

def test_991_is_prime():
    assert is_prime(991)

def test_993_is_not_prime():
    assert not is_prime(993)

def test_7873_is_prime():
    assert is_prime(7873)

def test_7802143_is_not_prime():
    assert not is_prime(7802143)

When we run pytest from the command line, here’s what we see:

~/project$ pytest
=========================== test session starts ===========================
platform linux -- Python 3.8.10, pytest-8.0.2, pluggy-1.4.0
rootdir: /home/michael/project/tests
plugins: anyio-4.3.0
collected 9 items                                                                                                                                                                                            

test_is_prime.py .........                                                                                                                                                                             [100%]

============================ 9 passed in 0.02s ============================

Our tests pass! It looks like is_prime is doing what it’s supposed to.

Step #2: Deploy your Heroku app

It’s time to wire up Heroku. Assuming you have a Heroku account and you’ve installed the Heroku CLI, creating your Heroku app is going to go pretty quickly.

Heroku will look in our project root folder for a file called requirements.txt, listing the Python dependencies our project has. This is what the file should look like:

fastapi==0.110.1
pydantic==2.7.0
uvicorn==0.29.0
pytest==8.0.2

Next, Heroku will look for a file called Procfile to determine how to start our Python application. Procfile should look like this:

web: uvicorn main:app --host=0.0.0.0 --port=${PORT}

With those files in place, let’s create our app.

~/project$ heroku login

~/project$ heroku apps:create is-it-prime

That was it? Yeah. That was it.

Step #3: Push your code to Heroku

Next, we push our project code to the git remote that the Heroku CLI set up when we created our app.

~/project$ git push heroku main
…
remote: -----> Launching...
remote:        Released v3
remote:        https://is-it-prime-2f2e4fe7adc1.herokuapp.com/ deployed to Heroku

So, that’s done. Let’s check our API.

$ curl https://is-it-prime-2f2e4fe7adc1.herokuapp.com/prime/91
false

$ curl https://is-it-prime-2f2e4fe7adc1.herokuapp.com/prime/7873
true

$ curl https://is-it-prime-2f2e4fe7adc1.herokuapp.com/prime/7802143
false

It works!

Step #4: Create a Heroku Pipeline to use Heroku CI

Now, we want to create a Heroku Pipeline with Heroku CI enabled so that we can run our tests.

We create the pipeline (called is-it-prime-pipeline), adding the app we created above to the staging phase of the pipeline.

$ heroku pipelines:create \
  --app=is-it-prime \
  --stage=staging \
  is-it-prime-pipeline

Creating is-it-prime-pipeline pipeline... done
Adding ⬢ is-it-prime to is-it-prime-pipeline pipeline as staging... done

With our pipeline created, we want to connect it to a GitHub repo so that our actions on the repo (such as new pull requests or merges) can trigger events in our pipeline (like automatically running the test suite).

$ heroku pipelines:connect is-it-prime-pipeline -r capnMB/heroku-ci-demo

Linking to repo... done

As you can see, I’m connecting my pipeline to my GitHub repo. When something like a pull request or a merge occurs in my repo, it will trigger the Heroku CI to run the test suite.

Next, we need to configure our test environment in an app.json manifest. Our file contents should look like this:

{
  "environments": {
    "test": {
      "formation": {
        "test": {
          "quantity": 1,
          "size": "standard-1x"
        }
      },
      "scripts": {
        "test": "pytest"
      }
    }
  }
}

This manifest contains the script we would use to run through our test suite. It also specifies the dyno size we (standard-1x) would want to use for our test environment. We commit this file to our repo.

Finally, in the web UI for Heroku, we navigate to the Tests page of our pipeline, and we click the Enable Heroku CI button.

After enabling Heroku CI, here’s what we see:

Step #5: Run your tests with Heroku CI

Just to demonstrate it, we can manually trigger a run of our test suite using the Heroku CLI:

$ heroku ci:run --pipeline is-it-prime-pipeline
…
-----> Running test command `pytest`...
========================= test session starts ============================
platform linux -- Python 3.12.3, pytest-8.0.2, pluggy-1.4.0
rootdir: /app
plugins: anyio-4.3.0
collected 9 items

tests/test_is_prime.py .........                                         [100%]

============================ 9 passed in 0.03s ============================

How does the test run look in our browser? We navigate to our pipeline and click Tests. There, we see our first test run in the left-side nav.

A closer inspection of our tests shows this:

Awesome. Now, let’s push some new code to a branch in our repo and watch the tests run!

We create a new branch (called new-test), adding another test case to test_is_prime.py. As soon as we push our branch to GitHub, here’s what we see at Heroku:

Heroku CI detects the pushed code and automates a new run of the test suite. Not too long after, we see the successful results:

Heroku CI for the win

If you’re using Heroku for your production environment—and you’re ready to go all in with DevOps—then using pipelines and Heroku CI may be the way to go.

Rather than using different tools and platforms for building, testing, reviewing, staging, and releasing to production… I can consolidate all these pieces in a single Heroku Pipeline. And with Heroku CI, I get automated testing with every push to my repo.

How To Build a Simple GitHub Action To Deploy a Django Application to the Cloud

Michael Bogan — Mon, 10 Jun 2024 14:25:13 +0000

Continuous integration and continuous delivery (CI/CD) capabilities are basic expectations for modern development teams who want fast feedback on their changes and rapid deployment to the cloud. In recent years, we’ve seen the growing adoption of GitHub Actions, a feature-rich CI/CD system that dovetails nicely with cloud hosting platforms such as Heroku. In this article, we’ll demonstrate the power of these tools used in combination—specifically how GitHub Actions can be used to quickly deploy a Django application to the cloud.

A Quick Introduction to Django

Django is a Python web application framework that’s been around since the early 2000s. It follows a model-view-controller (MVC) architecture and is known as the “batteries-included” web framework for Python. That’s because it has lots of capabilities, including a strong object-relational mapping (ORM) for abstracting database operations and models. It also has a rich templating system with many object-oriented design features.

Instagram, Nextdoor, and Bitbucket are examples of applications built using Django. Clearly, if Django is behind Instagram, then we know that it can scale well. (Instagram hovers around being the fourth most visited site in the world!)

Security is another built-in feature; authentication, cross-site scripting protection, and CSRF features all come out of the box and are easy to configure. Django is over 20 years old, which means it has a large dev community and documentation base—both helpful when you’re trying to figure out why something has gone awry.

Downsides to Django? Yes, there are a few, with the biggest one being a steeper learning curve than other web application frameworks. You need to know parts of everything in the system to get it to work. For example, to get a minimal “hello world” page up in your browser, you need to set up the ORM, templates, views, routes, and a few other things. Contrast that with a framework like Flask (which is, admittedly, less feature-rich), where less than 20 lines of code can get your content displayed on a web page.

Building Our Simple Django Application

If you’re not familiar with Django, their tutorial is a good place to start learning how to get a base system configured and running. For this article, I’ve created a similar system using a PostgreSQL database and a few simple models and views. But we won’t spend time describing how to set up a complete Django application. That’s what the Django tutorial is for.

My application here is different from the tutorial in that I use PostgreSQL—instead of the default SQLite—as the database engine. The trouble with SQLite (besides poor performance in a web application setting) is that it is file-based, and the file resides on the same server as the web application that uses it. Most cloud platforms assume a stateless deployment, meaning the container that holds the application is wiped clean and refreshed every deployment. So, your database should run on a separate server from the web application. PostgreSQL will provide that for us.

The source code for this mini-demo project is available in this GitHub repository.

Install Python dependencies

After you have cloned the repository, start up a virtual environment and install the Python dependencies for this project:



(venv) ~/project$ pip install -r requirements.txt

Set up Django to use PostgreSQL

To use PostgreSQL with Django, we use the following packages:

psycopg2 provides the engine drivers for Postgres.
dj-database-url helps us set up the database connection string from an environment variable (useful for local testing and cloud deployments).

In our Django app, we navigate to mysite/mysite/ and modify settings.py (around line 78) to use PostgreSQL.



DATABASES = {"default": dj_database_url.config(conn_max_age=600, ssl_require=True)}

We’ll start by testing out our application locally. So, on your local PostgreSQL instance, create a new database.



postgres=# create database django_test_db;

Assuming our PostgreSQL username is dbuser and the password is password, then our DATABASE_URL will look something like this:



postgres://dbuser:password@localhost:5432/django_test_db

From here, we need to run our database migrations to set up our tables.



(venv) ~/project$ \
  DATABASE_URL=postgres://dbuser:password@localhost:5432/django_test_db\
  python mysite/manage.py migrate

Operations to perform:
  Apply all migrations: admin, auth, contenttypes, movie_journal, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying movie_journal.0001_initial... OK
  Applying sessions.0001_initial... OK

Test application locally

Now that we have set up our database, we can spin up our application and test it in the browser.



(venv) ~/project$ \
  DATABASE_URL=postgres://dbuser:password@localhost:5432/django_test_db\
  python mysite/manage.py runserver

…
Django version 4.2.11, using settings 'mysite.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

In our browser, we visit http://localhost:8000/movie-journal. This is what we see:

We’re up and running! We can go through the flow of creating a new journal entry.

Looking in our database, we see the record for our new entry.



django_test_db=# select * from movie_journal_moviejournalentry;
-[ RECORD 1 ]+-------------------------------------------------------------
id           | 1
title        | Best of the Best
imdb_link    | https://www.imdb.com/title/tt0096913/
is_positive  | t
review       | Had some great fight scenes. The plot was amazing.
release_year | 1989
created_at   | 2024-03-29 09:36:59.24143-07
updated_at   | 2024-03-29 09:36:59.241442-07

Our application is working. We’re ready to deploy. Let’s walk through how to deploy using GitHub Actions directly from our repository on commit.

The Power of GitHub Actions

Over the years, GitHub Actions has built up a large library of jobs/workflows, providing lots of reusable code and conveniences for developers.

With CI/CD, a development team can get fast feedback as soon as code changes are committed and pushed. Typical jobs found in a CI pipeline include style checkers, static analysis tools, and unit test runners. All of these help enforce good coding practices and adherence to team standards. Yes, all these tools existed before. But now, developers don’t need to worry about manually running them or waiting for them to finish.

Push your changes to the remote branch, and the job starts automatically. Go on to focus on your next coding task as GitHub runs the current jobs and displays their results as they come in. That’s the power of automation and the cloud, baby!

Plug-and-play GitHub Action workflows

You can even have GitHub create your job configuration file for you. Within your repository on GitHub, click Actions. You’ll see an entire library of templates, giving you pre-built workflows that could potentially fit your needs.

Let’s click on the Configure button for the Pylint workflow. It looks like this:



name: Pylint

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.8", "3.9", "3.10"]
    steps:
    - uses: actions/checkout@v3
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pylint
    - name: Analysing the code with pylint
      run: |
        pylint $(git ls-files '*.py')

This configuration directs GitHub Actions to create a new workflow in your repository named Pylint. It triggers a push to any branch. It has one job, build, that runs the latest Ubuntu image. Then, it runs all the steps for each of the three different versions of Python specified.

The steps are where the nitty-gritty work is defined. In this example, the job checks out your code, sets up the Python version, installs dependencies, and then runs the linter over your code.

Let’s create our own GitHub Action workflow to deploy our application directly to Heroku.

Deploying to Heroku via a GitHub Action

Here’s the good news: it’s easy. First, sign up for a Heroku account and install the Heroku CLI.

Login, create app, and PostgreSQL add-on

With the Heroku CLI, we run the following commands to create our app and the PostgreSQL add-on:



$ heroku login

$ heroku apps:create django-github
Creating ⬢ django-github... done
https://django-github-6cbf23e36b5b.herokuapp.com/ | https://git.heroku.com/django-github.git

$ heroku addons:create heroku-postgresql:mini --app django-github
Creating heroku-postgresql:mini on ⬢ django-github... ~$0.007/hour (max $5/month)
Database has been created and is available
 ! This database is empty. If upgrading, you can transfer
 ! data from another database with pg:copy

Add Heroku app host to allowed hosts list in Django

In our Django application settings, we need to update the list of ALLOWED_HOSTS, which represent the host/domain names that your Django site can serve. We need to add the host from our newly created Heroku app. Edit mysite/mysite/settings.py, at around line 31, to add your Heroku app host. It will look similar to this:



ALLOWED_HOSTS = ["localhost", "django-github-6cbf23e36b5b.herokuapp.com"]

Don’t forget to commit this file to your repository.

Procfile and requirements.txt

Next, we need to add a Heroku-specific file called Procfile. This goes into the root folder of our repository. This file tells Heroku how to start up our app and run migrations. It should have the following contents:



web: gunicorn --pythonpath mysite mysite.wsgi:application
release: cd mysite && ./manage.py migrate --no-input

Heroku will also need your requirements.txt file so it knows which Python dependencies to install.

Get your Heroku API key

We will need our Heroku account API key. We’ll store this at GitHub so that our GitHub Action has authorization to deploy code to our Heroku app.

In your Heroku account settings, find the auto-generated API key and copy the value.

Then, in your GitHub repository settings, navigate to Secrets and variables > Actions.

On that page, click New repository secret. Supply a name for your repository secret and. Then, paste in your Heroku API key and click Add secret.

Your list of GitHub repository secrets should look like this:

Create the job configuration file

Let’s create our GitHub Action workflow. Typically, we configure CI/CD jobs with a YAML file. With GitHub Actions, this is no different.

To add an action to your repository, create a .github subfolder in your project, and then create a workflows subfolder within that one. In .github/workflows/, we’ll create a file called django.yml. Your project tree should look like this:



.
├── .git
│   └── …
├── .github
│   └── workflows
│       └── django.yml

├── mysite
│   ├── manage.py
│   ├── mysite
│   │   ├── …
│   │   └── settings.py
│   └── …
├── Procfile
└── requirements.txt

Our django.yml file has the following contents:



name: Django CI

on:
  push:
    branches: [ "main" ]

jobs:
  release:
     runs-on: ubuntu-latest
     steps:
       - uses: actions/checkout@v2
       - uses: akhileshns/heroku-deploy@v3.13.15
         with:
           heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
           heroku_app_name: "<your-heroku-app-name>"
           heroku_email: "<your-heroku-email>"

This workflow builds off of the Deploy to Heroku Action in the GitHub Actions library. In fact, using that pre-built action makes our Heroku deployment simple. The only things you need to configure in this file are your Heroku app name and account email.

When we commit this file to our repo and push our main branch to GitHub, this kicks off our GitHub Action job for deploying to Heroku. In GitHub, we click the Actions tab and see the newly triggered workflow. When we click the release job in the workflow, this is what we see:

Near the bottom of the output of the deploy step, we see results from the Heroku deploy:

When we look in our Heroku app logs, we also see the successful deploy.

And finally, when we test our Heroku-deployed app in our browser, we see that it’s up and running.

Congrats! You’ve successfully deployed your Django action to Heroku via a GitHub Action!

Conclusion

In this article, we set up a simple Django application with a PostgreSQL database. Then, we walked through how to use GitHub Actions to deploy the application directly to your Heroku on commit.

Django is a feature-rich web application framework for Python. Although for some cloud platforms, it can take some time to get things configured correctly, that’s not the case when you’re deploying to Heroku with GitHub Actions. Convenient off-the-shelf tools are available in both GitHub and Heroku, and they make deploying your Django application a breeze.

Working with Heroku Logplex for Comprehensive Application Logging

Michael Bogan — Tue, 28 May 2024 15:13:48 +0000

With the complexity of modern software applications, one of the biggest challenges for developers is simply understanding how their applications behave. Understanding the behavior of your app is key to maintaining its stability, performance, and security.

This is a big reason why we do application logging: to capture and record events through an application’s lifecycle, so that we can gain valuable insights into our application. What kinds of insights? Application activity (user interactions, system events, and so on), errors and exceptions, resource usage, potential security threats, and more.

When developers can capture and analyze these logs effectively, this improves application stability and security, which, in turn, improves the user experience. It’s a win-win for everybody.

Application logging is easy—if you have the right tools. In this post, we’ll walk through using Heroku Logplex as a centralized logging solution. We’ll start by deploying a simple Python application to Heroku. Then, we’ll explore the different ways to use Logplex to view and filter our logs. Finally, we’ll show how to use Logplex to send your logs to an external service for further analysis.

Ready to dive in? Let’s start with a brief introduction to Heroku Logplex.

Introducing Heroku Logplex

Heroku Logplex is a central hub that collects, aggregates, and routes log messages from various sources across your Heroku applications. Those sources include:

Dyno logs: generated by your application running on Heroku dynos.
Heroku logs: generated by Heroku itself, such as platform events and deployments.
Custom sources: generated by external sources, such as databases or third-party services.

By consolidating logs in a single, central place, Logplex simplifies log management and analysis. You can find all your logs in one place for simplified monitoring and troubleshooting. You can perform powerful filtering and searching on your logs. And you can even route logs to different destinations for further processing and analysis.

Core components

At its heart, Heroku Logplex consists of three crucial components that work together to streamline application logging:

Log sources are the starting points where log messages originate within your Heroku environment. They are your dyno logs, Heroku logs, and custom sources which we mentioned above.
Log drains are the designated destinations for your log messages. Logplex allows you to configure drains to route your logs to various endpoints for further processing. Popular options for log drains include:

External logging services with advanced log management features, dashboards, and alerting capabilities. Examples are Datadog, Papertrail, and Sumo Logic.
Notification systems that send alerts or notifications based on specific log entries, enabling real-time monitoring and troubleshooting.
Custom destinations such as your own Syslog or web server.
Log filters are powerful tools that act as checkpoints, allowing you to refine the log messages before they reach their final destinations. Logplex allows you to filter logs based on source, log level, and even message content. By using filters, you can significantly reduce the volume of data sent to your drains, focusing only on the most relevant log entries for that specific destination.

Routing and processing

As Logplex collects log messages from all your defined sources, it passes these messages through your configured filters, potentially discarding entries that don't match the criteria. Finally, filtered messages are routed to their designated log drains for further processing or storage.

Alright, enough talk. Show me how, already!

Integrating Logplex with Your Application

Let’s walk through how to use Logplex for a simple Python application. To get started, make sure you have a Heroku account. Then, download and install the Heroku CLI.

Demo application

You can find our very simple Python script (main.py) in the GitHub repo for this demo. Our script runs an endless integer counter, starting from zero. With each iteration, it emits a log message (cycling through log levels INFO, DEBUG, ERROR, and WARN). Whenever it detects a prime number, it emits an additional CRITICAL log event to let us know. We use isprime from the sympy library to help us determine if a number is prime.

To run this Python application on your local machine, first clone the repository. Then, install the dependencies:

(venv) ~/project$ pip install -r requirements.txt

Next, start up the Python application. We use gunicorn to spin up a server that binds to a port, while our prime number logging continues to run in the background. (We do this because a Heroku deployment is designed to bind to a port, so that’s how we’ve written our application even though we’re focused on logging).

(venv) ~/project$ gunicorn -w 1 --bind localhost:8000 main:app
[2024-03-25 23:18:59 -0700] [785441] [INFO] Starting gunicorn 21.2.0
[2024-03-25 23:18:59 -0700] [785441] [INFO] Listening at: http://127.0.0.1:8000 (785441)
[2024-03-25 23:18:59 -0700] [785441] [INFO] Using worker: sync
[2024-03-25 23:18:59 -0700] [785443] [INFO] Booting worker with pid: 785443
{"timestamp": "2024-03-25T23:18:59.507828Z", "level": "INFO", "name": "root", "message": "New number", "Number": 0}
{"timestamp": "2024-03-25T23:19:00.509182Z", "level": "DEBUG", "name": "root", "message": "New number", "Number": 1}
{"timestamp": "2024-03-25T23:19:01.510634Z", "level": "ERROR", "name": "root", "message": "New number", "Number": 2}
{"timestamp": "2024-03-25T23:19:02.512100Z", "level": "CRITICAL", "name": "root", "message": "Prime found!", "Prime Number": 2}
{"timestamp": "2024-03-25T23:19:05.515133Z", "level": "WARNING", "name": "root", "message": "New number", "Number": 3}
{"timestamp": "2024-03-25T23:19:06.516567Z", "level": "CRITICAL", "name": "root", "message": "Prime found!", "Prime Number": 3}
{"timestamp": "2024-03-25T23:19:09.519082Z", "level": "INFO", "name": "root", "message": "New number", "Number": 4}

Simple enough. Now, let’s get ready to deploy it and work with logs.

Create the app

We start by logging into Heroku through the CLI.

$ heroku login

Then, we create a new Heroku app. I’ve named my app logging-primes-in-python, but you can name yours whatever you’d like.

$ heroku apps:create logging-primes-in-python
Creating ⬢ logging-primes-in-python... done
https://logging-primes-in-python-6140bfd3c044.herokuapp.com/ | https://git.heroku.com/logging-primes-in-python.git

Next, we create a Heroku remote for our GitHub repo with this Python application.

$ heroku git:remote -a logging-primes-in-python
set git remote heroku to https://git.heroku.com/logging-primes-in-python.git

A note on requirements.txt and Procfile

We need to let Heroku know what dependencies our Python application needs, and also how it should start up our application. To do this, our repository has two files: requirements.txt and Procfile.

The first file, requirements.txt, looks like this:

python-json-logger==2.0.4
pytest==8.0.2
sympy==1.12
gunicorn==21.2.0

And Procfile looks like this:

web: gunicorn -w 1 --bind 0.0.0.0:${PORT} main:app

That’s it. Our entire repository has these files:

$ tree
.
├── main.py
├── Procfile
└── requirements.txt

0 directories, 3 files

Deploy the code

Now, we’re ready to deploy our code. We run this command:

$ git push heroku main
…
remote: Building source:
remote: 
remote: -----> Building on the Heroku-22 stack
remote: -----> Determining which buildpack to use for this app
remote: -----> Python app detected
…
remote: -----> Installing requirements with pip
…
remote: -----> Launching...
remote:        Released v3
remote:        https://logging-primes-in-python-6140bfd3c044.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done.

Verify the app is running

To verify that everything works as expected, we can dive into Logplex right away. Logplex is enabled by default for all Heroku applications.

$ heroku logs --tail -a logging-primes-in-python
…
2024-03-22T04:34:15.540260+00:00 heroku[web.1]: Starting process with command `gunicorn -w 1 --bind 0.0.0.0:${PORT} main:app`
…
2024-03-22T04:34:16.425619+00:00 app[web.1]: {"timestamp": "2024-03-22T04:34:16.425552Z", "level": "INFO", "name": "root", "message": "New number", "taskName": null, "Number": 0}
2024-03-22T04:34:17.425987+00:00 app[web.1]: {"timestamp": "2024-03-22T04:34:17.425837Z", "level": "DEBUG", "name": "root", "message": "New number", "taskName": null, "Number": 1}
2024-03-22T04:34:18.000000+00:00 app[api]: Build succeeded
2024-03-22T04:34:18.426354+00:00 app[web.1]: {"timestamp": "2024-03-22T04:34:18.426205Z", "level": "ERROR", "name": "root", "message": "New number", "taskName": null, "Number": 2}
2024-03-22T04:34:19.426700+00:00 app[web.1]: {"timestamp": "2024-03-22T04:34:19.426534Z", "level": "CRITICAL", "name": "root", "message": "Prime found!", "taskName": null, "Prime Number": 2}

We can see that logs are already being written. Heroku’s log format is following this scheme:

timestamp source[dyno]: message

Timestamp: The date and time recorded at the time the dyno or component produced the log line. The timestamp is in the format specified by RFC5424 and includes microsecond precision.
Source: All of your app’s dynos (web dynos, background workers, cron) have the source app. Meanwhile, all of Heroku’s system components (HTTP router, dyno manager) have the source heroku.
Dyno: The name of the dyno or component that wrote the log line. For example, web dyno #1 appears as web.1, and the Heroku HTTP router appears as router.
Message: The content of the log line. Logplex splits any lines generated by dynos that exceed 10,000 bytes into 10,000-byte chunks without extra trailing newlines. It submits each chunk that is submitted as a separate log line.

View and filter logs

We’ve seen the first option for examining our logs, the Heroku CLI. You can use command line arguments, such as --source and --dyno, to use filters and specify which logs to view.

To specify the number of (most recent) log entries to view, do this:

$ heroku logs --num 10

To filter down logs to a specific dyno or source, do this:

$ heroku logs --dyno web.1
$ heroku logs --source app

Of course, you can combine these filters, too:

$ heroku logs --source app --dyno web.1

The Heroku Dashboard is another place where you can look at your logs. On your app page, click More -> View logs.

Here is what we see:

If you look closely, you’ll see different sources: heroku and app.

Log Drains

Let’s demonstrate how to use a log drain. For this, we’ll use BetterStack (formerly Logtail). We created a free account. After logging in, we navigated to the Source page, and clicked Connect source.

We enter a name for our source and select Heroku as the source platform. Then, we click Create source.

After creating our source, BetterStack provides the Heroku CLI command we would use to add a log drain for sending logs to BetterStack.

Technically, this command adds an HTTPS drain that points to an HTTPS endpoint from BetterStack. We run the command in our terminal, and then we restart our application:

$ heroku drains:add \
"https://in.logs.betterstack.com:6515/events?source_token=YKGWLN7****************" \
-a logging-primes-in-python


Successfully added drain https://in.logs.betterstack.com:6515/events?source_token=YKGWLN7*****************

$ heroku restart -a logging-primes-in-python

Almost instantly, we begin to see our Heroku logs appear on the Live tail page at BetterStack.

By using a log drain to send our logs from Heroku Logplex to an external service, we can take advantage of the features from BetterStack to work with our Heroku logs. For example, we can create visualization charts and configure alerts on certain log events.

Custom drains

In our example above, we created a custom HTTPS log drain that happened to point to an endpoint from BetterStack. However, we can send our logs to any endpoint we want. We could even send our logs to another Heroku app! 🤯 Imagine building a web service on Heroku that only Heroku Logplex can make POST requests to.

Logging best practices

Before we conclude our walkthrough, let’s briefly touch on some logging best practices.

Focus on relevant events: Log only the information that’s necessary to understand and troubleshoot your application's behavior. Prioritize logging application errors, user actions, data changes, and other crucial activities.
Enrich logs with context: Include details that provide helpful context to logged events. Your future troubleshooting self will thank you. So, instead of just logging "User logged in," capture details like user ID, device information, and relevant data associated with the login event.
Embrace structured logging: Use a standardized format like JSON to make your logs machine-readable. This allows easier parsing and analysis by logging tools, saving you time in analysis.
Protect sensitive data: Never log anything that could compromise user privacy or violate data regulations. This includes passwords, credit card information, or other confidential data.
Take advantage of log levels: Use different log levels (like DEBUG, INFO, WARNING, and ERROR) to categorize log events based on their severity. This helps with issue prioritization, allowing you to focus on critical events requiring immediate attention.

Conclusion

Heroku Logplex empowers developers and operations teams with a centralized and efficient solution for application logging within the Heroku environment. While our goal in this article was to provide a basic foundation for understanding Heroku Logplex, remember that the platform offers a vast array of advanced features to explore and customize your logging based on your specific needs.
As you dig deeper into Heroku’s documentation, you’ll come across advanced functionalities like:

Customizable log processing: Leverage plugins and filters to tailor log processing workflows for specific use cases.
Real-time alerting: Configure alerts based on log patterns or events to proactively address potential issues.
Advanced log analysis tools: Integrate with external log management services for comprehensive log analysis, visualization, and anomaly detection. By understanding the core functionalities and exploring the potential of advanced features, you can leverage Heroku Logplex to create a robust and efficient logging strategy. Ultimately, good logging will go a long way in enhancing the reliability, performance, and security of your Heroku applications.

Caching RESTful API requests with Heroku’s Redis Add-on

Michael Bogan — Wed, 17 Apr 2024 13:39:30 +0000

Most software developers encounter two main problems: naming things, caching, and off-by-one errors. 🤦🏻‍♂️

In this tutorial, we’ll deal with caching. We’ll walk through how to implement RESTful request caching with an open source-licensed version of Redis. We’ll also set up and deploy this system easily with Heroku.

For this demo, we’ll build a Node.js application with the Fastify framework, and we’ll integrate caching with Redis to reduce certain types of latency.

Ready to dive in? Let’s go!

Node.js + Fastify + long-running tasks

As I’m sure our readers know, Node.js is a very popular platform for building web applications. With its support for JavaScript (or TypeScript, or both at the same time!), Node.js allows you to use the same language for both the frontend and the backend of your application. It also has a rich event loop that makes asynchronous request handling more intuitive.

The concurrency model in Node.js is very performant, able to handle upwards of 15,000 requests per second. But even then, you might still run into situations where the request latency is unacceptably high. We’ll show this with our application.

As you follow along, you can always browse the codebase for this mini demo at my GitHub repository.

Initialize the basic application

By using Fastify, you can quickly get a Node.js application up and running to handle requests. Assuming you have Node.js installed, you’ll start by initializing a new project. We’ll use npm as our package manager.

After initializing a new project, we will install our Fastify-related dependencies.

~/project$ npm i fastify fastify-cli fastify-plugin

Then, we update our package.json file to add two scripts and turn on ES module syntax. We make sure to have the following lines:

  "type": "module",
  "main": "app.js",
  "scripts": {
    "start": "fastify start -a 0.0.0.0 -l info app.js",
    "dev": "fastify start -p 8000 -w -l info -P app.js"
  },

From there, we create our first file (routes.js) with an initial route:

// routes.js

export default async function (fastify, _opts) {
  fastify.get("/api/health", async (_, reply) => {
    return reply.send({ status: "ok" });
  });
}

Then, we create our app.js file that prepares a Fastify instance and registers the routes:

// app.js
import routes from "./routes.js";

export default async (fastify, opts) => {
  fastify.register(routes);
};

These two simple files—our application and our route definitions—are all we need to get up and running with a small Fastify service that exposes one endpoint: /api/health. Our dev script in package.json is set to run the fastify-cli to start our server on localhost port 8000, which is good enough for now. We start up our server:

~/project$ npm run dev

Then, in another terminal window, we use curl to hit the endpoint:

~$ curl http://localhost:8000/api/health 
{"status":"ok"}

Add a simulated long-running process

We’re off to a good start. Next, let’s add another route to simulate a long-running process. This will help us gather some latency data. In routes.js, we add another route handler within our exported default async function:

 fastify.get("/api/user-data", async (_, reply) => {
    await sleep(5000);
    const userData = readData();
    return reply.send({ data: userData });
  });

This exposes another endpoint: /api/user-data. Here, we have a method to simulate reading a lot of data from a database (readData) and a long-running process (sleep). We define those methods in routes.js as well. They look like this:

import fs from "fs";

function readData() {
  try {
    const data = fs.readFileSync("data.txt", "utf8");
    return data;
  } catch (err) {
    console.error(err);
  }
}

function sleep(ms) {
  return new Promise((resolve) => {
    setTimeout(resolve, ms);
  });
}

With our new route in place, we restart our server (npm run dev).

Measure latency with curl

How do we measure latency? The simplest way is to use curl. Curl captures various time profiling metrics when it makes requests. We just need to format curl’s output so that we can easily see the various latency values available. To do this, we define the output we want to see with a text file (curl-format.txt):

    time_namelookup:  %{time_namelookup}s\n
        time_connect:  %{time_connect}s\n
     time_appconnect:  %{time_appconnect}s\n
    time_pretransfer:  %{time_pretransfer}s\n
       time_redirect:  %{time_redirect}s\n
  time_starttransfer:  %{time_starttransfer}s\n
  -------------------  ----------\n
          time_total:  %{time_total}s\n

With our output format defined, we can use it with our next curl call:

curl -w "@curl-format.txt" \
     -o /dev/null -s \
     "http://localhost:8000/api/user-data"

The response we receive looks like this:

  time_namelookup:  0.000028s
        time_connect:  0.000692s
     time_appconnect:  0.000000s
    time_pretransfer:  0.000772s
       time_redirect:  0.000000s
  time_starttransfer:  5.055683s
                       ----------
          time_total:  5.058479s

Well, that’s not good. Over five seconds is way too long for a transfer time (the time it takes the server to actually handle the request). Imagine if this endpoint was being hit hundreds or thousands of times per second! Your users would be frustrated, and your server may crash under the weight of continually re-doing this work.

Redis to the rescue!

Caching your responses is the first line of defense to reduce your transfer time (assuming you’ve addressed any of the poor programming practices that might be causing the latency!). So, let’s assume we’ve done everything we can do to reduce latency, but our application still needs five seconds to put this complex data together and return it to the user.

In our scenario, because the data is the same every time for every request to /api/user-data, we have a perfect candidate for caching. With caching, we’ll perform the necessary computation once, cache the result, and return the cached value for all subsequent requests.

Redis is a performant, in-memory key/value store, and it’s a common tool used for caching. To leverage it, we first install Redis on our local machine. Then, we need to add Fastify’s Redis plugin to our project:

~/project$ npm i @fastify/redis

Register the Redis plugin with Fastify

We create a file, redis.js, which configures our Redis plugin and registers it with Fastify. Our file looks like this:

// redis.js

const REDIS_URL = process.env.REDIS_URL || "redis://127.0.0.1:6379";

import fp from "fastify-plugin";
import redis from "@fastify/redis";

const parseRedisUrl = (redisUrl) => {
  const url = new URL(redisUrl);
  const password = url.password;
  return {
    host: url.hostname,
    port: url.port,
    password,
  };
};

export default fp(async (fastify) => {
  fastify.register(redis, parseRedisUrl(REDIS_URL));
});

Most of the lines in this file are dedicated to parsing a REDIS_URL value into a host, port, and password. If we have REDIS_URL set properly at runtime as an environment variable, then registering Redis with Fastify is simple. After configuring our plugin, we just need to modify app.js to use it:

// app.js

import redis from "./redis.js";
import routes from "./routes.js";

export default async (fastify, opts) => {
  fastify.register(redis);
  fastify.register(routes);
};

Now we have access to our Redis instance by referencing fastify.redis anywhere within our app.

Modify our endpoint to use caching

With Redis in the mix, let’s change our /api/user-data endpoint to use caching:

  fastify.get("/api/user-data", async (_, reply) => {
    const { redis } = fastify;

    // check if data is in cache
    const data = await redis.get("user-data", (err, val) => {
      if (val) {
        return { data: val };
      }
      return null;
    });

    if (data) {
      return reply.send(data);
    }

    // simulate a long-running task
    await sleep(5000);
    const userData = readData();


    // add data to the cache
    redis.set("user-data", userData);


    return reply.send({ data: userData });
  });

Here, you see that we’ve hardcoded in Redis a single key, user-data, and stored our data under that key. Of course, our key could be a user ID or some other value that identifies a particular type of request or state. Also, we could set a timeout value to expire our key, in the case that we expect data to change after a certain window of time.

If there is data in the cache, then we’ll return it and skip all the time-consuming work. Otherwise, do the long-running computation, add the result to the cache, and then return it to the user.

What do our transfer times look like after hitting this endpoint two more times (the first one to add the data into the cache, and the second one to retrieve it)?

   time_namelookup:  0.000023s
        time_connect:  0.000560s
     time_appconnect:  0.000000s
    time_pretransfer:  0.000729s
       time_redirect:  0.000000s
  time_starttransfer:  0.044512s
                       ----------
          time_total:  0.047479s

Much better! We’ve reduced our request times from several seconds to milliseconds. That’s a huge improvement in performance!

Redis has many more features that may be useful here, including having key/value pairs timeout after a certain amount of time; that’s a more common scenario in production environments.

Using Redis in your Heroku deployment

Up to this point, we’ve only shown how this works in a local environment. Now, let’s go one step further and deploy it all to the cloud. Fortunately, Heroku provides many options for deploying web applications and working with Redis. Let’s walk through how to get set up there.

After signing up for a Heroku account and installing their CLI tool, we’re ready to create a new app. In our case, we’ll call our app fastify-with-caching. Here are our steps:

Step 1: Login to Heroku

~/projects$ heroku login
...
Logging in... done

Step 2: Create the Heroku app

When we create our Heroku app, we’ll get back our Heroku app URL. We take note of this because we’ll use it in our subsequent curl requests.

~/project$ heroku create -a fastify-with-caching
Creating ⬢ fastify-with-caching... done
https://fastify-with-caching-3e247d11f4ad.herokuapp.com/ | https://git.heroku.com/fastify-with-caching.git

Step 3: Add the Redis add-on

We need to set up a Redis add-on that meets our application’s needs. For our demo project, it’s sufficient to create a Mini-tier Redis instance:

~/project$ heroku addons:create heroku-redis:mini -a fastify-with-caching
Creating heroku-redis:mini on ⬢ fastify-with-caching…
…
redis-transparent-98258 is being created in the background.
…

Spinning up the Redis instance may take two or three minutes. We can check the status of our instance periodically:

~/project$ heroku addons:info redis-transparent-98258
...
State:        creating

Not too long after, we see this:

State:        created

We’re just about ready to go!

When Heroku spins up our Redis add-on, it also adds our Redis credentials as config variables attached to our Heroku app. We can run the following command to see these config variables:

~/project$ heroku config -a fastify-with-caching
=== fastify-with-caching Config Vars

REDIS_TLS_URL: rediss://:p171d98f7696ab7eb2319f7b78083af749a0d0bb37622fc420e6c1205d8c4579c@ec2-18-213-142-76.compute-1.amazonaws.com:15940
REDIS_URL:     redis://:p171d98f7696ab7eb2319f7b78083af749a0d0bb37622fc420e6c1205d8c4579c@ec2-18-213-142-76.compute-1.amazonaws.com:15939

(Your credentials, of course, will be unique and different from what you see above.)

Notice that we have a REDIS_URL variable all set up for us. It’s a good thing our redis.js file is coded to properly parse an environment variable called REDIS_URL.

Step 4: Create a Heroku remote

Finally, we need to create a Heroku remote in our git repo so that we can easily deploy with git.

~/project$ heroku git:remote -a fastify-with-caching
set git remote heroku to https://git.heroku.com/fastify-with-caching.git

Step 5: Deploy!

Now, when we push our branch to our Heroku remote, Heroku will build and deploy our application.

~/project$ git push heroku main
...
remote: Building source:
remote: 
remote: -----> Building on the Heroku-22 stack
remote: -----> Determining which buildpack to use for this app
remote: -----> Node.js app detected
remote:        
remote: -----> Creating runtime environment
...
remote: -----> Compressing...
remote:        Done: 50.8M
remote: -----> Launching...
remote:        Released v4
remote:        https://fastify-with-caching-3e247d11f4ad.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done.

Our application is up and running. It’s time to test it.

Test our deployed application

We start with a basic curl request to our /api/health endpoint:

$ curl https://fastify-with-caching-3e247d11f4ad.herokuapp.com/api/health
{"status":"ok"}

Excellent. That looks promising.

Next, let’s send our first request to the long-running process and capture the latency metrics:

$ curl \
  -w "@curl-format.txt" \
  -o /dev/null -s \
  https://fastify-with-caching-3e247d11f4ad.herokuapp.com/api/user-data

     time_namelookup:  0.035958s
        time_connect:  0.101336s
     time_appconnect:  0.249308s
    time_pretransfer:  0.249389s
       time_redirect:  0.000000s
  time_starttransfer:  5.384986s
  -------------------  ----------
          time_total:  6.554382s

When we send the same request a second time, here’s the result:

$ curl \
  -w "@curl-format.txt" \
  -o /dev/null -s \
  https://fastify-with-caching-3e247d11f4ad.herokuapp.com/api/user-data

     time_namelookup:  0.025807s
        time_connect:  0.091763s
     time_appconnect:  0.236050s
    time_pretransfer:  0.236119s
       time_redirect:  0.000000s
  time_starttransfer:  0.334859s
  -------------------  ----------
          time_total:  1.276264s

Much better! Caching allows us to bypass the long-running processes. From here, we can build out a much more robust caching mechanism for our application across all our routes and processes. We can continue to lean on Heroku and Heroku’s Redis add-on when we need to deploy our application to the cloud.

Bonus Tip: Clearing the cache for future tests

By the way, if you want to test this more than once, then you may occasionally need to delete the user-data key/value pair in Redis. You can use the Heroku CLI to access the Redis CLI for your Redis instance:

~$ heroku redis:cli -a fastify-with-caching
Connecting to redis-transparent-98258 (REDIS_TLS_URL, REDIS_URL):
ec2-18-213-142-76.compute-1.amazonaws.com:15940> DEL user-data
1

Conclusion

In this tutorial, we explored how caching can greatly improve your web service's response time in cases where identical requests would produce identical responses. We looked at how to implement this with Redis, the industry-standard caching tool. We did this all with ease within a Node.js application that leverages the Fastify framework. Lastly, we deployed our demo application to Heroku, using their built-in Heroku Data for Redis instance management to cache in the cloud.

Happy coding!

Getting to Know You - Speeding up Developer Onboarding with LLMs and Unblocked

Michael Bogan — Mon, 08 Jan 2024 14:03:55 +0000

As anyone who has hired new developers onto an existing software team can tell you, onboarding new developers is one of the most expensive things you can do. One of the most difficult things about onboarding junior developers is that it takes your senior developers away from their work.

Even the best hires might get Imposter Syndrome, since they feel like they need to know more than they do and need to depend on their peers. You might have the best documentation, but it can be difficult to figure out where to start with onboarding.

Onboarding senior developers takes time and resources as well.

With the rise of LLMs, it seems like putting one on your code, documentation, chats, and ticketing systems would make sense. The ability to converse with an LLM trained on the right dataset would be like adding a team member who can make sure no one gets bogged down with sharing something that’s already documented. I thought I’d check out a new service called Unblocked that does just this.

In this article, we will take a spin through a code base I was completely unfamiliar with and see what it would be like to get going on a new team with this tool.

Data Sources

If you’ve been following conversations around LLM development, then you know that they are only as good as the data they have access to. Fortunately, Unblocked allows you to connect a bunch of data sources to train your LLM.

Additionally, because this LLM will be working on your specific code base and documentation, it wouldn’t even be possible to train it on another organization’s data. Unblocked isn’t trying to build a generic code advice bot. It’s personalized to your environment, so you don’t need to worry about data leaking to someone else.

Setting up is pretty straightforward, thanks to lots of integrations with developer tools. After signing up for an account, you’ll be prompted to connect to the sources Unblocked supports.

You'll need to wait a few minutes or longer depending on the size of your team while Unblocked ingests your content and trains the model.

Getting started

I tried exploring some of the features of Unblocked. While there’s a web dashboard that you’ll interact with most of the time, I recommend you install the Unblocked Mac app, also. The app will run in your menu bar and allow you to ask Unblocked a question from anywhere. There are a bunch of other features for teammates interacting with Unblocked. I may write about those later, but for now, I just like that it gives me a universal shortcut (Command+Shift+U) to access Unblocked at any time.

Another feature of the macOS menu bar app is that it provides a quick way to install the IDE Plugins based on what I have installed on my machine. Of course, you don’t have to install them this way (Unblocked does this install for you), but it takes some of the thinking out of it.

Asking Questions

Since I am working on a codebase that is already in Unblocked, I don’t need to wait for anything after getting my account set up on the platform. If you set up your code and documentation, then you won’t need your new developers to wait either.

Let’s take this for a spin and look at what questions a new developer might ask the bot.

I started by asking a question about setting up the frontend.

This answer looks pretty good! It’s enough to get me going in a local environment without contacting anyone else on my team. Unblocked kept everyone else “unblocked” on their work and pointed me in the right direction all on its own.

I decided to ask about how to get a development environment set up locally. Let’s see what Unblocked says if I ask about that.

This answer isn’t what I was hoping for … but I can click on the README link and find that this is not really Unblocked’s fault. My team just hasn’t updated the README for the backend app, and Unblocked found the incorrect boilerplate setup instructions. Now that I know where to go to get the code, I’ll just update it after I have finished setting up the backend on my own. In the meantime, though, I will let Unblocked know that it didn’t give me the answer I hoped for.

Since it isn’t really the bot’s fault that it’s wrong, I made sure to explain that in my feedback.

I had a good start, but I wanted some more answers to my architectural questions. Let’s try something a little more complicated than reading the setup instructions from a README.

This is a pretty good high-level overview, especially considering that I didn’t have to do anything, other than type them in. Unblocked generated these answers with links to the relevant resources for me to investigate more as needed.

Browse the code

I actually cloned the repos for the frontend and backend of my app to my machine and opened them in VS Code. Let’s take a look at how Unblocked works with the repos there.

As soon as I open the Unblocked plugin while viewing the backend repository, I’m presented with recommended insights asked by other members of my team. There are also some references to pull requests, Slack conversations, and Jira tasks that the bot thinks are relevant before I open a single file.

This is useful. As I open various files, the suggestions change with the context, too.

Browse components

The VS Code plugin also called out some topics that it discovered about the app I’m trying out. I clicked on the Backend topic, and it took me to the following page:

All of this is automatically generated, as Unblocked determines the experts for each particular part of the codebase. However, experts can also update their expertise when they configure their profiles on our organization. Now, in addition to having many questions I can look at about the backend application, I also know which of my colleagues to go to for questions.

If I go to the Components page on the Web Dashboard, I can see a list of everything Unblocked thinks is important about this app. It also gives me a quick view of who I can talk to about these topics. Clicking on any one of them provides me with a little overview, and the experts on the system can manage these as needed. Again, all of this was automatically generated.

Conclusion

This was a great start with Unblocked. I’m looking forward to next trying this out on some of the things that I’ve been actively working on. Since the platform is not going to be leaking any of my secrets to other teams, I’m not very concerned at all about putting it on even the most secret of my projects and expect to have more to say about other use cases later.

Unblocked is in public beta and free and worth checking out!

Exploring the Cadence Access Model: Fine-Grained permissions for flow contracts

Michael Bogan — Mon, 13 Nov 2023 15:11:58 +0000

**Flow **is a permissionless layer-1 blockchain built to support the high-scale use cases of games, virtual worlds, and the digital assets that power them. The blockchain was created by the team behind Cryptokitties, Dapper Labs, and NBA Top Shot.

One core attribute that differentiates Flow from the other blockchains is its way of providing fine-grained permissions to objects within the blockchain. Fine-grained access is a new method of providing access to users that follows the principle of least privilege. This makes it highly secure and fault-resistant. Flow is one of the unique blockchains to have this, as it is built on the fundamentals of Capability-based security.

But how does this help you as a developer? If you’re writing smart contracts, then you likely have to regularly define access to objects and functions within your contract. Understanding the different types of access better will help you to define access types in code more accurately. This will allow you to write highly secure and efficient smart contracts.

Let’s dive in.

Source

Understanding fine-grained permissions

As opposed to Role-based access control (RBAC), where permissions are defined loosely for every role and not specifically for every individual, fine-grained permissions allow developers to define permissions for objects at the lowest level. This allows permissions to be defined for every object. This also allows you to add new permissions types, such as time-expiry and geography-based permissions.

Let’s understand the core principle behind fine-grained permissions.

The principle of least privilege

The concept of least privilege means that in a computing environment, any module (such as a process, a user, or a programmer) only has the necessary access that it needs to do its specific job. Any other unnecessary permissions for its specific job are either revoked or unavailable.

For example, a programmer whose job is to create backups does not need to make user data updates, so it should only have read permissions on the database of users. This principle is the core principle behind fine-grained permissions.

Capability-based Security

A capability is an unforgeable token of authority. In capability-based authorization, your identity does not matter. If you’ve been sent an access token by the owner/admin that grants you the capability to access a resource and you can execute that capability, then you will have access. Hence, at runtime, the application does not check what your identity is but only that you can access the requested resource. Thus, fine-grained access can be implemented on the foundations of capability-based security.

History of fine-grained access

In the 1980s, operating systems would define permissions on objects as “read”, “write”, and “execute”. This was called Access Control Lists. In the 1990s, Role-based Access Control was introduced, which allowed you to create groups and assign users to groups. Then, the concepts of attribute-based access control and capability-based access control arrived, which brought fine-grained access into the picture. In the world of blockchains, however, fine-grained access is new and brought by Cadence, the language used to write Flow smart contracts.

Fine-grained access in Cadence

Cadence, the language used to write flow smart contracts, has built-in special keywords to allow for fine-grained permissions to resources. Below, we dive into the common keywords and the usage of these keywords to provide fine-grained access.

The access keywords

Flow defines certain keywords, known as access keywords, with different parameters to define the access privileges of a certain resource. Below are the four primary keywords:

Pub or access(all)

Using this keyword means the declaration is accessible in all scopes. However, this also means that the declaration is not updatable except when you’re updating the value at an index of an array. Pub or access(all) are the least restrictive types of access and should generally be avoided. Below is an example of using the pub keyword:

pub contract Car {
    pub let carBrand: String
    pub let carNameByBrand: {String: String}
    pub fun returnCarBrand(): String {
        return self.carBrand
    }
}
}

Following the above code example, if there’s an object called CarObject of type Car, then the statement below invocation is valid.

CarObject.carBrand //Equals the value of greeting in the object

The values with access type pub are generally not updatable except when updating the value at a certain index of an array.

CarObject.carNameByBrand = {} //Not Valid
CarObject.carNameByBrand[“Porsche”] = “Carrera” //Valid

access(self)

access(self) means that the declaration is only visible in the current and inner scopes. For example, an access(self) field can only be accessed by the functions of the type it is a part of.

When using access(self), it is common practice to define setters and getter methods to allow other objects and contracts to access this field.

This keyword makes the usage very safe but also restrictive. Below is an example of using access(self):

pub contract Car {
    access(self) let carBrand: String
    access(self) let carNameByBrand: {String: String}
    pub fun returnCarBrand(): String {
        return self.carBrand
    }
    pub fun returnCarName(_ brand: String): String? {
        return self.carNameByBrand[brand]
    }
}
}

access(contract)

access(contract) means that the declaration is only accessible in the scope of the contract that defines it. Hence, functions defined in other contracts under the same account or functions defined in contracts under other accounts will not be able to access it. This keyword is unique to Cadence and comes in handy when you have any contract-specific variables you don’t want to expose to other contracts.

Below is an example of using the access(contract) keyword:

pub contract CarContract {
    pub struct Car {
        access(contract) var carBrand: String
    }
    pub fun returnCarBrand(_brand: Car): String {
        return Car.carBrand
    }
}
}

In the above example, if you have a method in a different contract that has an object of the Car struct, you cannot get the carBrand variable directly. However, you can call the returnCarBrand function to get the value of carBrand.

access(account)

This keyword means that the declaration is only accessible inside the entire account owned by the current smart contract. Hence, other contracts in the same account can access a variable freely. This type of access is very powerful, allowing you to keep a variable private to your account. You are also able to deploy a smart contract that needs to use the variable in the future, if needed. This way, several contracts in the same account can share information seamlessly with one another, promoting the modularity of code.

Below is an example of how to use it:

pub contract CarContract {
    pub struct Car {
        access(account) var carBrand: String
    }
    pub fun returnCarBrand(_brand: Car): String {
        return Car.carBrand
    }
}
}

In the above example, if you have a method in a different contract that has an object of the Car struct, you can get the carBrand variable directly.

Conclusion

The concept of least privilege and capability-based security play a significant role in Flow's precise permissions. The access keywords provide clear definitions of variable and function access, as we have covered in this article.

One of the most noteworthy features that fundamentally strengthens the security of the Flow blockchain is its fine-grained access control. Blockchain technology has long been plagued by bugs and hacks, most of which occur because of ill-conceived access controls. However, fine-grained access control provides developers with a remarkable opportunity to effortlessly and smoothly secure their smart contracts. Ultimately, this is what sets Flow apart in the world of blockchain.

On the topic of fine-grained permissions, hopefully you found this in-depth exploration valuable and helpful. For more information, refer to the official documentation. Or explore the Flow Docs and get some hands-on experience!

The Power of Resource-Oriented Programming in Flow/Cadence: A Deep Dive

Michael Bogan — Wed, 01 Nov 2023 14:16:58 +0000

Flow is a permissionless layer-1 blockchain built to support the high-scale use cases of games, virtual worlds, and the digital assets that power them. The blockchain was created by the team behind CryptoKitties, Dapper Labs, and NBA Top Shot.

One of the best features of Flow is that it supports the paradigm of resource-oriented programming. Resource-oriented programming is a new way of managing memory where resources are held “in-situ” by the resource owner instead of in a separate ledger. This is very relevant for managing scarce and unreplicable digital resources on the blockchain.

In this article, I’ll do a deep dive into resource-oriented programming—and allow you to better manage your resources in your Flow smart contracts.

Source

What is resource-oriented programming?

In resource-oriented programming, objects are labeled as “resources”. Resources are a collection of variables and functions that only have exactly one copy at a time. Resources provide better composability than EVM and WASM.

When something is called a resource, there are very specific rules for interacting with it. The three rules that apply to resources in resource-oriented programming are as follows:

Each resource exists in only one memory location - Resources cannot be duplicated.
Ownership of a resource is defined by where it is stored - No central ledger that keeps track of ownership
Only the owner of the resource can access its methods.

To explain this better: In the real world, if you claim to own a watch, that ownership is proven by the fact that you possess it yourself. There is no central ledger that people refer to check if you are the owner. However, in programming, when we think of ownership, we think of a mapping somewhere in a ledger of the object ID to the owner ID. For example, in the case of ERC721 smart contracts, the ownership of digital assets is stored in a ledger owned by the main smart contract.

Flow changes this paradigm of ownership by storing “resources” in the memory location owned by the owner itself (see image below). This means that if you’re holding a digital asset on the Flow blockchain, it is stored in the memory location of the account that you own.

This has several benefits, which we’ll talk about in the coming section.

A depiction of memory allocation for resources in Cadence

Resources in Cadence

Cadence is the world’s first high-level resource-oriented programming language. Move, created for Facebook’s now defunct Diem, is the only other language that is resource-oriented, but it is more low-level.

In Cadence, resources are defined using the “resource” keyword. Within a resource, you can define the attributes of the resource, like variables and functions. This definition of a resource now becomes a type and can be used to create objects of that type.

An example of creating a resource and creating an instance of that resource is shown below:

// Declare a resource that only includes one function.
    pub resource CarAsset {


        // A transaction can call this function to get the "Honk Honk!"
        // message from the resource.
        pub fun honkHorn(): String {
            return "Honk Horn!"
        }
    }


    // We're going to use the built-in create function to create a new instance
    // of the Car resource
    pub fun createCarAsset(): @CarAsset {
        return <-create CarAsset()
    }

Destroy function

Resources in Cadence can be explicitly destroyed using the “destroy” keyword. A resource object cannot go out of scope and be dynamically lost. It must be destroyed or moved before the end of scope.

Below is a cadence example of how to use destroy:

    let d <- create SomeResource(value: 20)
    destroy d

The Move Operator (<-)

To make the moves of a resource explicit, the Move operator, such as “<-”, must be used when:

Initializing the value of a constant or variable with a resource
Moving resources to a different variable
Moving resources to the argument of a function
Returning it from a function

Below is a cadence example of how to use the Move (“<-”) operator

    let d <- create SomeResource(value: 20)
    let new_resource <- d

Code Example of Creating a Resource in Cadence

Below is an example of a Cadence script that creates a CryptoKitty collection as a resource and also stores individual Kitties as a resource.

contract CryptoKitties {
    // Accounts store a collection in their account storage

    resource KittyCollection {
    // Each collection has functions to
    // move stored resources in and out

    fun withdraw(kittyId: int): CryptoKitty
        fun deposit(kitty: CryptoKitty)
    }

    // The resource objects that can be stored in the collection
    resource CryptoKitty {}
}


transaction(signer: Account) {
    // Removes the Kitty from signer's collection, and stores it
    // temporarily on the stack.


    let theKitty <- signer.kittyCollection.withdraw(kittyId: myKittyId)


    // Moves the Kitty into the receiver's account
    let receiver = getAccount(receiverAccountId)
    receiver.kittyCollection.deposit(kitty: <-theKitty)
}

In the above code, we create a KittyCollection resource that has several CryptoKitty sub-resources within it. We then do a transfer transaction to transfer a Kitty from one user account to another.

Other things to keep in mind

Resources must be created using the “create” keyword.
At the end of a function with resources, the resources should either be moved or destroyed.
Accessing a field or a function of a resource does not destroy it.
When a resource is moved, the constant or variable currently holding the resource becomes invalid.
To make a resource type explicit, the prefix @ must be used in type annotations.

Comparison and Benefits

Resource-oriented programming versus ledger-based systems

A common comparison of the ownership structure in resource-oriented programming is with ledger-based ownership. In the ledger model, like in ERC721 smart contracts, every time you have to update ownership, you need to update the mapping of the ID in a shared ledger.

In resource-oriented programming, resources are stored within the account of the owner itself, so transferring a digital asset only means moving the resource from the first party to the second. This does not require updating any ledgers. Resource-oriented programming is more suitable for blockchain use cases like digital assets than the traditional ledger system.

Benefits of resource-oriented programming

There are several benefits that resource-oriented programming brings to the table. Let’s look at some of them below.

Makes capability-based security possible

Resource types provide the foundation on which capability-based security can be established. Capabilities are one of the best methods to create highly secure blockchain authorization systems. This brings the utmost security to the Flow blockchain.

Better protection again reentrancy attacks

Reentrancy attacks are one of the most severe smart contract vulnerabilities often exploited by hackers. In a reentrancy attack, a hacker calls the withdraw function on a smart contract recursively. This way, they are able to drain the entire funds of a smart contract. Due to the architecture of cadence, re-entrancy attacks are much less likely to occur. Read more in this article about the DAO hack and how cadence is safe from it.

Better pricing and cost management

In Ethereum, the CryptoKitties contract has 2 million digital assets collectively taking up more than 100 MB of space, living rent-free on the Ethereum blockchain. In an ideal world, it should be possible to charge the owners of Kitties based on how much of this data belongs to them on-chain. In Flow, since the resource is directly stored in the account of the owner, it is clear who needs to pay the cost for that data.

Conclusion

Resource-oriented programming is a new and innovative programming paradigm that has been brought to the blockchain world by the Flow blockchain. It makes resource management very efficient, easy, and secure. It also helps provide a better cost-sharing model for running blockchain infrastructure.

You can refer to the official docs page on Resources to learn more. I also recommend that you get your hands dirty by going through Flow Docs and this tutorial on Resources.

Giving Power Back to Your Users with Flow’s Account Model

Michael Bogan — Wed, 25 Oct 2023 15:19:56 +0000

Many alternative blockchains that have emerged recently are classified as “EVM” chains, meaning they operate exactly like Ethereum but have a different execution layer. This helps the cross-compatibility of smart contracts across chains, but it doesn’t solve some of the crucial problems embedded in the EVM system. In particular, it hasn’t improved how user accounts are handled and protected.

Flow, a layer-1 blockchain, is trying to change that pattern with its account model. In this article, we’ll look in detail at that new account model, how it works, and how it might be able to solve some of the most difficult UX problems in blockchain.

How do Accounts on Ethereum Work?

One of the best ways to understand how the Flow account model excels is to compare it to Ethereum. There are two types of accounts on Ethereum: externally owned accounts (EOA), which are your typical consumer wallets, and then smart contract accounts.

EOAs have a public and private key pair, where the public key is derived from the private key and works as an address for the account, and the private key signs transactions on the blockchain. They can hold a balance and interact with other accounts, primarily smart contract accounts.

These smart contract accounts are compiled byte code that run on the Ethereum Virtual Machine. What’s really interesting is that any data created by the smart contract, such as tokens or NFTs, is stored in that smart contract. Instead of an EOA truly owning the token, the smart contract simply says who owns what and how much.

Ethereum’s potential security gaps

Not only is true digital ownership conceded, but smart contracts on Ethereum are hard to read and audit for security. A great number of scams and “rug pulls” have occurred on EVM chains because of this power imbalance. Such a scam would usually look like this: A website, which looks very similar to a popular NFT project, touts a new collection at a reasonable mint price. People visit the site, connect their wallet, and when they click that mint button, they will likely get a screen with a bunch of blockchain byte code that tells them nothing about what will happen if they sign. It could just mint an NFT, or it could completely deplete their wallet. Without the ability to read the transactions well, wallets are not able to give the end user much info as to what will happen when they sign. (Note that Flow, covered in more detail below, has a better transaction format that allows wallets to clearly tell the end user what will happen when they sign, giving more balance and control to the user.)

How do Accounts on Flow work?

The Flow account model combines the concepts of the EOA and smart contract accounts from Ethereum into a single standard. In this model, the account and the public keys are decoupled. As stated earlier, Ethereum accounts only have a public and private key, and they are tied to the account itself. This is important as it enables better control and reduces potential mistakes made by the end user, ultimately helping protect their assets.

With the Flow account model, you can have a single account with multiple public and private keys. Having multiple keys is a huge advantage because you can revoke or rotate keys that might be compromised, again giving the user better control and security. Not only that, but these keys are weighted keys, giving them the ability to do more complex transactions such as multiple signatures.These signatures are used frequently in blockchain to let multiple users sign one transaction, similar to how you might need two keys to open a bank vault. In the EVM model this has to be built out manually, but with Flow it is readily available.

Image courtesy of Flow Documentation

Since there can be multiple keys for one account, the way Flow creates addresses is also unique. Unlike Ethereum—where addresses are derived from the public key—Flow account addresses are created with an internal on-chain checksum at the protocol level. This ensures addresses are unique.

In addition, Flow gives developers and users the option of different signature and hash algorithm curves such as secp256k1 (used primarily by Bitcoin and other cryptocurrencies) or the more flexible P-256 (which is adopted by most cell phones and computers). These options provide better flexibility and compatibility with other protocols and ultimately give users top-notch security, all on devices they already use daily. And since encryption and cryptography are always evolving, it’s critical and necessary to adopt the latest standards.

Storage with Flow

Another thing unique to Flow’s account model is its storage capabilities. On Ethereum, only smart contract accounts have the ability to store data and thus truly own assets. You can think of it like leasing a car: if you lease one you do get to drive it and park it at your house, but it's not truly yours. There’s a contract saying you own the car under certain terms, and the ultimate power is in that contract— and its terms may not always favor the lessee.

On the other hand, Flow accounts allow for asset storage and for accounts to deploy their own smart contracts. The account storage used is calculated by the byte size of data currently stored in the account, and it is directly tied to the balance of Flow tokens on the account.

True digital ownership: buy, don’t lease

This is truly special as it gives users the ability to truly own the digital items they purchase, rather than a smart contract putting their name on it. Flow manages this storage by the amount of Flow tokens the account has, including a minimum storage feed of 0.001 $FLOW which equates to 100Kb of data. (This is to make sure it can handle any incoming assets.)

If for any reason the account attempts a transaction that would exceed its storage capacity, then the transaction will fail. In the Flow account model, that car is in your garage with no contracts tied to it! Paid in full.

Image courtesy of Flow Documentation

Conclusion

Flow is trying to diverge from the normal EVM path. In the Ethereum world, there are many cases of users losing funds partly due to the account model on EVM chains, which makes it difficult for users to read and interpret what will happen when they press a button on a website. Flow is aiming to empower users to own their digital assets and ensure funds will only leave their account with their permission. Flow also gives developers flexibility, making things like multi-signature weighted keys native to the platform, as well as multiple signature and hashing algorithms to choose from for the best compatibility among devices and networks.

It’s early, but these kinds of features are needed in web3 UX, and could be a potential game-changer.

Smart Contract Language Comparison - Cadence vs Solidity vs Move

Michael Bogan — Wed, 27 Sep 2023 14:32:42 +0000

When starting a new web3 project, it’s important to make the right choices about the blockchain and smart contract language. These choices can significantly impact the overall success of your project as well as your success as a developer.

In this article, we'll compare three popular smart contract programming languages:

Solidity: used in Ethereum and other EVM-based platforms
Cadence: used in the Flow blockchain
Move: used in the Sui/Aptos blockchain

We'll explain the concepts and characteristics of each language in simple terms, making it easier for beginners to understand. Let’s dive in.

Solidity: The Foundation of Ethereum Smart Contracts

Solidity is a high-level, object-oriented language used to build smart contracts in platforms like Ethereum. Initially, Solidity aimed to be user-friendly, attracting developers by resembling JavaScript and simplifying learning. While it still values user-friendliness, its focus has shifted to enhancing security. Currently, Solidity has quite a few security pitfalls developers need to be aware of.

Some Solidity features include:

Syntax and Simplicity: Solidity uses clear, explicit code with a syntax similar to JavaScript, prioritizing ease of understanding for developers.
Security Focus: Solidity emphasizes secure coding practices and highlights risky constructs like gas usage.
Statically Typed: The language enforces data type declarations for variables and functions.
Inheritance and Libraries: Solidity supports features like inheritance, libraries, and complex user-defined types.

Cadence: Empowering Digital Assets on Flow

Cadence is designed by Flow, a blockchain known for helping to make web3 mainstream and working with major brands like Disney and the NBA. It ensures secure, clear, and approachable smart contract development.

Some Cadence features include:

Type Safety: The language enforces strict type checking to prevent common errors.
Resource-oriented Programming: Resources are unique, linear types that can only move between accounts and can’t ever be copied or implicitly discarded. If a function fails to store a Resource obtained from an account in the function scope during development, then semantic checks will flag an error. The run-time enforces the same strict rules in terms of allowed operations. Therefore, contract functions that do not properly handle Resources in scope before exiting will abort, reverting them to the original storage.

These Resource features make them perfect for representing both fungible and non-fungible tokens. Ownership is tracked according to where they are stored, and the assets can’t be duplicated or accidentally lost since the language itself enforces correctness.

Capability-based Security: If one person wants to access another person's stored items, the first person needs a permission called a Capability. Using Capabilities allows you to let others access your stored items remotely.

There are two types of Capabilities: public and private. If someone wants to allow everyone to access their items, they can share a public Capability. For instance, an account can use a public Capability to accept tokens from anyone. On the other hand, someone can also give private Capabilities to specific people, allowing them to access certain features. For example, in a project that involves unique digital items, the project owners might give specific people an "administrator Capability" that lets them create new items.

(image from Guide for Solidity developers | Flow Developer Portal)

Built-in Pre- and Post-Conditions: Functions have predefined conditions for safer execution.
Optimized for Digital Assets: Cadence's focus on resource-oriented programming makes it ideal for managing digital assets in areas such as onchain games.
Freedom from msg.sender: To grasp the importance of these new ideas, let's take a quick look at some history. In 2018, the Dapper Labs team began working on Cadence as a new programming language. They faced challenges with Solidity because of its limitations. The main frustration in building decentralized apps came from the way contracts were accessed using addresses, making it difficult to combine contracts.

Composability in Web3

Now, imagine contracts as Lego building blocks. Composability in web3 means one contract can be used as a foundation for others, adding their features together.

For instance, if a contract records game results on a blockchain, another contract can be built to show the best players. Another one could go even further and use past game results to predict future game odds for betting. But here's the catch: Because of how Solidity works, contracts can only talk to one another if the first contract has permission to access the second one, even if users can access both.

In Solidity, who can do what is controlled by protected functions in contracts. This means contracts know and check who is trying to access their protected areas.

(image from Guide for Solidity developers | Flow Developer Portal)

Cadence changes how access works. Instead of using the old way where contracts need permission, it uses Capabilities. When you have a Capability, you can use it to get to a protected item such as a function or resource. This means the contract no longer has to define who's allowed access. You can only get to the protected item if you have a Capability, which you can use with "borrow()". So, the old "msg.sender" way isn't needed anymore!

(image from Guide for Solidity developers | Flow Developer Portal)

The effects of composability are important. When contracts don't need to know beforehand who they're interacting with, users can easily interact with multiple contracts and their functions during a transaction if they have the right permissions (Capabilities). This also allows contracts to interact with one another directly, without needing special permissions or preparations. The only condition is that the calling contract must have the required Capabilities.

Move: Safeguarding Digital Assets on Sui/Aptos

Move, used in the Sui/Aptos blockchain, addresses challenges posed by established languages like Solidity. It ensures scarcity and access control for digital assets.
Move's features include:

Preventing Double-spending: Move prevents the creation or use of assets more than once, ensuring robust blockchain applications.
Ownership and Rights Control: Developers have precise control over ownership and associated rights.
Module Structure: In Move, a smart contract is called a module, emphasizing modularity and organization.
Bytecode Verifier: Move employs static analysis to reject invalid bytecode, enhancing security.
Standard Library: Move includes a standard library for common transaction scripts.

Creating Smart Contracts

Let's illustrate the differences by comparing a simple smart contract that increments a value in Cadence, Solidity, and Move.

Solidity Example

In Solidity, creating a contract that increments a value involves defining a contract, specifying the count variable, and creating functions to manipulate it. It uses explicit syntax for variable visibility and function declarations.

// SPDC-License-Identifier: MIT
pragma solidity ^0.8.17;

contract Counter {
    uint public count;

    // function to get the current count
    function get() public view returns (uint) {
        return count;
    }

    // function to increment count by 1
    function inc() public {
        count += 1;
    }

    // function to decrement count by 1
    function dec() public {
        count -=1;
    }
}

Cadence Example

Cadence's approach to incrementing a value is similar but emphasizes clarity. It utilizes a resource-oriented structure and straightforward syntax, making it easier for developers to create and manage digital assets.

pub contract Counter {
    pub var count: Int

    // function to increment count by 1
pub fun increment() {
        self.count = self.count +1
    }

    // function to decrement count by 1
    pub fun decrement() {
        self.count = self.count – 1
    }

    pub fun get(): Int {
        return self.count
    }

    init() {
        self.count = 0
    }
}

Solidity versus Cadence Syntax Differences

In Solidity, the visibility keyword comes before or after variable/function names, whereas Cadence consistently follows the visibility-type-name sequence.

*Scalability and Upgradability *
Flow's network boasts higher transaction throughput than Ethereum, making Cadence more scalable. Additionally, Flow's support for contract updates enhances development.

Move Example

Move introduces new concepts like modules, resources, and ownership control. A Move module creates an Incrementer resource, requiring the owner's signature for operations.

module incrementer_addr::increment {

    use aptos_framework::account;
    use std::signer;

    struct Incrementer has key {
        count: u64,
    }

    public entry fun increment(account: &signer) acquires Incrementer {
        let signer_address = signer::address_of(account);
        let c_ref = &mut borrow_global_mut<Incrementer>(signer_address).count;
        *c_ref = *c_ref +1
    }

        public entry fun create_incrementer(account: &signer){
           let incrementer = Incrementer {
           count: 0
           };
           move_to(account, incrementer);
       }
}

*Composite Types and Turing Completeness *
All three languages support composite types, allowing complex types from simpler ones. All are Turing complete, meaning they can handle any computation given enough resources.

Resource-Oriented versus Object-Oriented
While Solidity and Move require compilation, Cadence is interpreted. Cadence and Move employ a resource-oriented approach, securing digital ownership in one location.

Conclusion: Choosing the Right Programming Language

When selecting a programming language like Solidity, Cadence, or Move, consider the needs of your project.

Solidity: Solidity is commonly used, but it might not be very easy to work with. Developers need to be careful of the security pitfalls and understand best practices.
Cadence: Mainly used for digital assets, Cadence is a newer language that focuses on security, is easy to understand, and provides developers with a superior experience.
Move: Move is based on Rust, a more complex language. Rust can be more difficult to learn and understand. Move is a new language, and it doesn't have many tools, resources, or a big community.

Ultimately, your choice will impact your project's success, so make an informed decision and enjoy your journey as a web3 developer!