DEV Community: Eduardo Rabelo

Declarative Automation Bundle: Bind an Existing Lakeflow Job

Eduardo Rabelo — Tue, 25 Aug 2026 13:44:26 +0000

A matching YAML configuration file does not adopt the Lakeflow Job already in your workspace. Bind the bundle resource key to that Lakeflow Job, then let the first deployment update the right ID.

Suppose refresh-orders already runs in production every morning.

An engineer created it manually in the Databricks workspace user interface months ago. It has run history, notifications, a schedule, and a notebook that somebody still edits by hand.

We want the Lakeflow Job in Git. We do not want a second Lakeflow Job, a changed schedule, or a first deployment from somebody's laptop.

The risky step is not generating YAML configuration. It is the first databricks bundle deploy.

A Declarative Automation Bundle tracks deployed objects by ID in a state file in the Databricks workspace. The Databricks CLI does not match a Lakeflow Job by name. If the state file does not map the resource key to the existing Lakeflow Job ID, the Databricks CLI treats the Lakeflow Job as new.

This article adopts one existing scheduled Lakeflow Job into one production bundle target. It has only workspace notebook tasks and no paginated collection with more than 100 items.

I am not moving Lakeflow Jobs between bundles. I am not designing continuous integration, changing run_as, or hardening the Lakeflow Job. Those are separate changes after this adoption succeeds.

Use this only after the bundle passes its development or user acceptance testing suite and existing production release controls. The Lakeflow Job and target already meet Manuka standards.

The four values that must agree

Before I run a bundle command, I write down four values:

the existing Lakeflow Job ID
the bundle resource key
the target name
the identity that will deploy this target later

Our example uses these values:

Lakeflow Job ID: 6565621249
Resource key: refresh_orders
Target:       prod
Deployer:     the production release service principal

The resource key is the YAML configuration identifier under resources.jobs. It is not the Lakeflow Job display name.

# resources/refresh_orders.job.yml (fragment, not deployable alone)
resources:
  jobs:
    refresh_orders:
      name: refresh-orders

The key identifies the bundle declaration. name is the Lakeflow Job name engineers see in the Databricks workspace.

The target selects a workspace and its deployment state file. By default, the Declarative Automation Bundle uses this workspace root path:

/Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target}

For the refresh_team bundle in the prod target, a release service principal might use:

/Workspace/Users/deploy-prod-<UUID>/.bundle/refresh_team/prod

A developer named Ana uses a different path:

/Workspace/Users/ana@example.com/.bundle/refresh_team/prod

The deployer part changes, so the service principal and Ana use separate deployment state files.

That identity detail changes the adoption sequence. I bind with the same production service principal that will run future production deployments. A bind through a developer's profile records the mapping in that developer's state file. The continuous integration workflow then sees no mapping and can still plan a create.

Databricks recommends a service principal for production deployments. It also recommends granting write access to the production root path only to that principal. Do not use /Shared for that path.

Binding has one narrow effect. It records that refresh_orders refers to Lakeflow Job 6565621249 in this target's state file. It does not apply the YAML configuration to the Lakeflow Job until the next deployment.

The key, target, and ID each answer a different question:

Value	Question it answers	Example
Resource key	Which YAML configuration declaration is this?	`refresh_orders`
Target	Which workspace state file receives the mapping?	`prod`
Lakeflow Job ID	Which existing Lakeflow Job does it manage?	`6565621249`

Do not replace the ID with the Lakeflow Job name. A Declarative Automation Bundle stores resource IDs in the workspace state file. It does not use the display name to discover an existing Lakeflow Job.

The deploying identity also needs permission to manage the existing Lakeflow Job. CAN_MANAGE is the Lakeflow Job-level permission that allows an identity to edit the definition and schedule. Confirm that access before the pull request reaches the bind step.

Capture the Lakeflow Job before you turn it into code

I capture the remote definition first. This gives the pull request something concrete to compare with the generated files.

The identity that captures or generates the Lakeflow Job needs CAN_VIEW on the production Lakeflow Job.

JOB_ID=6565621249

databricks jobs get "$JOB_ID" \
  --include-trigger-state \
  --output json > refresh-orders.before.json

The command writes the Lakeflow Job definition and its trigger state to refresh-orders.before.json. Store it in the pull request summary or ticket, not in the repository if it contains sensitive configuration.

This walkthrough assumes the response contains every Lakeflow Job array on its first page. If jobs get returns next_page_token, I use a separate migration and capture every page.

Next, I run the generator from the bundle project root. I keep its generated files uncommitted until the review is complete.

databricks bundle generate job \
  --existing-job-id "$JOB_ID" \
  --key refresh_orders \
  --target prod

The generator creates a Lakeflow Job configuration under resources/. It also downloads its Databricks workspace notebook files under src/.

The generated YAML configuration is evidence. It is not a reason to deploy immediately.

Run as is the identity the Lakeflow Job uses for its tasks. It is separate from the bundle's deploying identity.

I compare the generated files with refresh-orders.before.json. I check the Lakeflow Job name, task keys, notebook paths, schedule, pause state, parameters, notifications, and Run as. I also check every file the Lakeflow Job references.

This is where I stop unrelated improvements. A new timeout, adjusted retry count, or better notification list makes the first deployment harder to reason about. I usually open follow-up pull requests for those changes.

If the Lakeflow Job uses Git source or a task type that the generator does not support, I stop this walkthrough here. I use a separate migration.

The review has one simple rule: the first bundle YAML configuration must describe the Lakeflow Job we already operate. It is not the place to make it better.

Review item	What I compare	Why it matters now
Task graph	Task keys and dependencies	A missing task changes the Lakeflow Job's work.
Source	Notebook paths and downloaded files	A path change can run different code.
Trigger	Cron expression, timezone, and pause state	A changed trigger can skip or duplicate a scheduled run.
Runtime settings	Parameters, `Run as`, and concurrency	A setting can change who runs work or how often.
Notifications	Failure recipients and destinations	The on-call team must keep receiving failures.

I keep refresh-orders.before.json outside the generated resources/ and src/ directories. The saved response records the Lakeflow Job at adoption.

Validate, bind, plan, then deploy

I commit the generated configuration and downloaded source files before binding. Git now holds the proposed definition, but the Databricks workspace Lakeflow Job remains unmanaged.

First, I validate the rendered production configuration:

databricks bundle validate --strict -t prod

Validation checks the bundle configuration. It does not prove that the YAML configuration describes the existing Lakeflow Job. The comparison in the previous section does that work.

Next, I bind the bundle resource key to the remote Lakeflow Job ID. The one-time adoption workflow uses --auto-approve.

Binding is non-interactive and records state only. It does not apply the YAML configuration to the Lakeflow Job.

databricks bundle deployment bind refresh_orders "$JOB_ID" \
  -t prod \
  --auto-approve

I use this one-time adoption exception because a useful plan needs the binding. An unbound plan can only show a create.

The workflow publishes the summary and plan. I review both before approving the deployment. This exception does not change the Lakeflow Job during binding.

Now I confirm the binding and inspect the first deployment plan:

databricks bundle summary -t prod --force-pull -o json
databricks bundle plan -t prod

The summary must map refresh_orders to Lakeflow Job 6565621249. The plan must not show create jobs.refresh_orders. If it does, I stop.

An update is not itself a failure. bundle generate job downloads notebooks and uses bundle paths. That can change a Lakeflow Job task's deployed notebook path.

I verify every planned update against the capture. An unexplained change to the task graph, trigger, Run as, parameters, or notifications stops the deployment.

I review and approve that plan before the workflow runs the first deployment:

databricks bundle deploy -t prod

Run this command through the release path. The first deploy changes the source of truth from workspace edits to the reviewed bundle configuration.

The deliberate pause point sits between bind and deploy. Binding records the association but does not update the Lakeflow Job. I can still stop, fix the YAML configuration, or remove the association.

If I bound the wrong key, ID, or target before the first deployment, I remove only the association:

databricks bundle deployment unbind refresh_orders -t prod

Unbind leaves the Lakeflow Job in the Databricks workspace running. It only removes the link from this bundle state. I do not deploy while the YAML configuration remains unbound, because the next deployment would create a new Lakeflow Job.

After the first deployment, unbind is not a configuration rollback. It does not restore the Lakeflow Job settings that the deploy applied.

To recover with a bundle change, I bind the existing Lakeflow Job again, inspect the plan, then deploy the corrected YAML configuration. I use refresh-orders.before.json as the pre-adoption reference.

What fails when I skip the bind

Consider the tempting shortcut. I generate YAML configuration, review it, and deploy without binding.

The resource key is present in the bundle. The Lakeflow Job name might even match exactly. Neither fact gives the Databricks CLI the existing Lakeflow Job ID.

The deployment state file has no mapping for refresh_orders. The Databricks CLI therefore plans to create the Lakeflow Job declared in YAML configuration.

That can leave two scheduled Lakeflow Jobs. One is the old Databricks workspace user interface-created Lakeflow Job. The other is the new bundle-created Lakeflow Job. Both can point at the same notebook and start work independently.

Binding replaces that uncertainty with an explicit mapping. It says that this key manages this Lakeflow Job ID in this target. The next deployment updates that Lakeflow Job according to the reviewed configuration.

The pattern I recommend

I use one adoption pull request for one existing Lakeflow Job in one target:

Capture the Lakeflow Job.
Generate and review the configuration without improving it.
Validate the target, bind the resource key, and inspect the plan.
Deploy through the same release identity.

Positives

The existing Lakeflow Job keeps its identity instead of being recreated.
The first plan can expose an unintended Lakeflow Job change before deployment.
Future deployments use the production service principal's bundle state.

Negatives

The adoption needs production release credentials before the first bind.
Manual workspace edits become drift and a later deploy can overwrite them.
Each target needs its own review and binding to its own existing Lakeflow Job ID.

The negatives are worth accepting. A production Lakeflow Job should have one declared owner and one reviewed deployment path.

Verify the handover

After deployment, I run these three read-only checks from the production release identity:

databricks jobs get "$JOB_ID" --output json
databricks bundle plan -t prod
databricks bundle summary -t prod --force-pull

The first command confirms that Lakeflow Job 6565621249 still exists. The plan should not propose creating a Lakeflow Job. The summary reads the remote state file and gives the reviewer the Databricks workspace link for the managed Lakeflow Job.

I watch the next scheduled run through the existing failure notification path. I expect one run from the same Lakeflow Job ID, using the same schedule. That is the first production measurement after the handover.

Do not use this article for a Lakeflow Spark Declarative Pipeline, Lakeflow Connect gateway, or Lakeflow Job already tracked by another bundle. Each has different state and recovery concerns.

Unity Catalog Schemas in Declarative Automation Bundles Are a Footgun

Eduardo Rabelo — Fri, 21 Aug 2026 15:06:29 +0000

Why mode: development quietly renames your schemas, why the official escape hatch makes things worse for teams, and four safer patterns to structure your deployments instead.

Last week a teammate ran databricks bundle deploy against our dev workspace.

The command failed with an error about a schema that already existed.

She had not touched that schema. Nobody had. Her code was identical to mine, and my deploy had worked minutes earlier.

This guide walks you through why that happens.

We start with the pieces, we watch the failure happen step by step, and then I show you four patterns that avoid the problem completely. One of them needs no extra tooling at all.

Declarative Automation Bundles in one minute

A Declarative Automation Bundle, or DAB, is a set of YAML files in your repository that describes Databricks resources: jobs, pipelines, dashboards, schemas. You run databricks bundle deploy, and the CLI creates or updates those resources on your workspace.

It is infrastructure as code for the Databricks platform.

The YAML lives in your repo next to your source code. Data engineers use it to ship work without clicking through the workspace UI. Deployment is manual, you run the command when you want it to run.

Since CLI version 1.3.0, deploys run on the direct engine by default. The CLI does not use Terraform anymore. The engine is the part of the CLI that talks to the Databricks APIs and applies your changes.

Meet our example bundle

Everything in this guide uses one small bundle called sales-analytics. It lives in two files:

sales-analytics/
├── databricks.yml
└── resources/
    └── reporting.schema.yml

The top-level file names the bundle and holds the shared settings we will build up: variables and targets.

# databricks.yml
bundle:
  name: sales-analytics

The schema resource inside resources/ appears in the walkthrough section.

Two worlds with opposite rules

When you run databricks bundle deploy, the CLI records what it created in a deployment state file.

With an unmodified setup, that file lands in your user folder on the workspace:

/Workspace/Users/ana@gmail.com/.bundle/sales-analytics/dev/state/deployment.json

That location is a default, not a law. You can move it with the workspace.root_path setting, though most teams never change it. Production mode even validates that your paths do not point at one specific user.

The state file records what you deployed.

My state file sits under my own email.

Yours sits under yours.

Two developers deploying the same repo never share a state file.

Unity Catalog is Databricks' governance layer.

A schema in Unity Catalog is a named container for tables and views, and it lives in a catalog.

Here is the important part: a catalog and its schemas belong to the metastore, not to any person.

If a schema named reporting exists in catalog main, every user sees that same main.reporting.

There is exactly one of it.

So bundles mix two worlds with opposite rules:

State files are private. One per developer.
Schemas are global. One per metastore.

Most of the time these worlds never collide, because development mode adds a safety layer between them.

Let us look at that layer, because it is also where the footgun lives.

What each deployment mode does

A target is a named deployment environment, such as dev, uat, or prod. You pick one with the -t flag.

A well-built bundle has targets, and each target sets its mode:

# databricks.yml
targets:
  dev:
    mode: development
    default: true
  uat: {}
  prod:
    mode: production

The mode decides how a deploy behaves. Here is the full picture:

	`mode: development`	`mode: production`	mode unset (uat above)
Resource name prefixing	Yes. Jobs get `[dev ana] nightly-ingest`. Schemas get a sanitised form like `dev_ana_reporting`	No. Names deploy exactly as declared	No. Names deploy exactly as declared
Schedules and triggers	All paused, regardless of your YAML	Stay active as configured	Stay active as configured
Concurrent job runs	Forced open, up to four at once, for fast iteration	As configured	As configured
Deployment lock	Disabled for faster iteration	Enabled	Enabled
Guardrails	None. Built for speed	Checks the git branch when you pin one, expects `run_as` and `permissions`, rejects user-specific paths	None
Use it for	Personal sandboxes in a shared workspace	Shared environments like uat and prod	Simple bundles or single-deployer setups

The schema prefix is not the pretty bracketed string. Schema names allow only letters, numbers, and underscores.

So the CLI removes brackets and spaces: [dev ana] becomes dev_ana_, and my schema reporting lands as dev_ana_reporting.

Second, the prefix comes from your identity, so every developer gets their own copy. That is isolation working as designed, and it only happens where humans deploy side by side.

So far so good... right?

The footgun

Your notebooks and pipelines usually expect a stable schema name. Maybe a query hardcodes main.reporting. After a dev-mode deploy, that schema is called dev_ana_reporting, and the query breaks.

This surprises everyone the first time. It looks like a bug. It is not: it is the safety layer doing its job.

The obvious next move is to search the docs, find an escape hatch, and switch it off:

# databricks.yml
experimental:
  skip_name_prefix_for_schema: true

The flag does exactly what it says. Jobs keep their prefix. Schemas lose theirs. Every developer now deploys a schema called plain reporting into catalog main, no matter who runs the deploy.

It feels harmless, but it is not!

Remember our two worlds: private state files, global schemas.

With the flag on, every developer's private state file claims the same public object.

Here is what happens next:

Ana deploys first. The CLI creates schema main.reporting. No prefix. Ana's state file records that she created it. The deploy succeeds.
Ben deploys ten minutes later. His state file is empty, so the CLI tries to create the schema fresh. It sends a create request for main.reporting.
Databricks refuses. The schema already exists, and Ben does not own it. On the direct engine the error names the resource and carries the API message, something like Error: cannot create resources.schemas.reporting: Schema 'main.reporting' already exists. Either way, his deploy fails.
Ben asks Ana to delete her deployment so he can test. Ana runs databricks bundle destroy -t dev. Bundles always force-delete schemas they manage, warning first that underlying data may be lost. Her state file says she owns main.reporting, so the CLI drops it, tables included. The schema vanishes for everyone.
Now Ben deploys successfully and owns the very schema Ana needs. When Ana redeploys, she hits the same wall Ben did.

The second hazard: toggling the flag

There is a second hazard that most people miss.

Inside a bundle, a resource's name is its identity. Change the effective name, and the CLI treats it as a brand-new resource.

So if you deploy with prefixes, then add the flag later, the CLI creates unprefixed schemas and deletes the prefixed ones.

Your data goes through that cycle too.

If you switch this flag on or off, the next deploy can delete schemas and their data. It is not a small settings change.

One reassurance before the patterns: this failure is a development-mode story.

Most teams deploy to uat and prod from a build system using one robot account, called a service principal. One robot account means no collision.

I lived through version one of this story... taking turns failing!

Do not reach for the flag. Reach for one of these four patterns instead.

Pattern 1: Accept the prefix and plan your code around it

The simplest pattern needs zero extra tooling. Leave everything as Databricks designed it, and make your code read the schema name at runtime instead of hardcoding it.

The trick is a prefix variable with a different value per target.

Dev derives it from your username, uat uses a fixed string, and prod uses none. The short_name substitution is your username without the domain, so ana@gmail.com becomes ana:

# databricks.yml
variables:
  catalog:
    description: Catalog for this deployment.
    default: main
  schema_prefix:
    description: Prefix for schema names in this environment.
    default: ""

targets:
  dev:
    mode: development
    default: true
    variables:
      schema_prefix: dev_${workspace.current_user.short_name}_
  uat:
    variables:
      schema_prefix: uat_
  prod:
    mode: production

Every consumer of the schema builds its name from that variable:

# resources/ingest.job.yml
resources:
  jobs:
    ingest:
      parameters:
        - name: source_catalog
          default: ${var.catalog}
        - name: source_schema
          default: ${var.schema_prefix}reporting

One YAML file, three outcomes. Ana deploying to dev passes her notebook dev_ana_reporting. The same job deployed to uat reads uat_reporting. In prod it reads plain reporting. Your notebook calls dbutils.widgets.get("source_schema") and never cares which stage triggered the run.

The schema resource itself keeps its plain name, name: reporting. The CLI adds its own prefix on top in dev.

Never put ${var.schema_prefix} inside the resource name. The CLI would stack its prefix on top of yours, and you would get a schema called dev_ana_dev_ana_reporting.

Positives

Nothing new to build, host, or permission. It is pure YAML you already have.
Full lifecycle stays in one place. Deploy, redeploy, and destroy all work.
Isolation is automatic. Nobody can collide with anybody.
Destroy cleans up everything, including the schemas.

Negatives

Every consumer of the schema must take the name dynamically. Hardcoded queries break.
You rely on the exact shape of the sanitised prefix, dev_<username>_. It is stable today, but it is a convention, not a contract.
Prefixed names look odd in Catalog Explorer and confuse newcomers.
Some external tools cannot accept dynamic names, which blocks this pattern.

Pick this pattern when your stack already passes configuration around, which good data pipelines do anyway.

Pattern 2: Declare schemas outside the bundle

Schemas often outlive the code that fills them. A natural split is to manage schemas somewhere else entirely: a Terraform module, a small provisioning script, or even a one-off manual setup for stable internal schemas.

# schemas.tf
resource "databricks_schema" "reporting" {
  catalog_name = "main"
  name         = "reporting"
}

Your product bundle keeps deploying jobs and pipelines, and simply points at main.reporting, which nobody's deploy mode can rename.

Set permissions on the schema in the same Terraform module with a databricks_grants resource, so access control travels with the schema.

Positives

Stable, clean names in every environment. Code stays hardcoded and boring.
The product bundle contains no schemas, so the prefix question never arises.
Terraform brings plan previews and catches drift, which is when someone changes schemas outside the tool.

Negatives

Two sources of truth. New joiners must learn where each thing lives.
Manual or scripted setup drifts and does not scale across environments.
Terraform adds state management, credentials, and a second tool to operate.
Deleting the bundle leaves the schemas behind. Cleanup lives in the other tool now.

Pick this pattern when a platform team already owns governance as code, or when schemas are genuinely shared infrastructure rather than project output.

Pattern 3: Put schemas in their own bundle

A middle path keeps everything as bundles but splits ownership. Create a second, tiny bundle that declares only the UC objects. Its targets never set mode: development, so nothing ever gets prefixed:

# sales-analytics-schemas/databricks.yml
bundle:
  name: sales-analytics-schemas

targets:
  dev: {}
  uat: {}
  prod: {}

Deploy it once per environment from CI using a service principal. Product developers never touch it, and because exactly one identity deploys it, the collision story from earlier cannot happen. Even the skip flag would be safe here, though you will not need it.

Positives

Stable names with full infrastructure-as-code discipline. Best of both worlds.
One deployer identity removes the multi-developer hazard completely.
Clear ownership boundary: platform owns schemas, teams own compute and code.

Negatives

A second bundle means a second pipeline, repo or folder, and set of secrets.
Ordering matters. Schemas must exist before product deploys reference them.
Someone will eventually run it locally without noticing the missing dev mode.

Pick this pattern when you want IaC end to end and can afford a small platform-style repo.

Pattern 4: Give every developer a catalog

If developers need clean schema names and full self-service, flip the isolation up one level. Instead of letting dev mode rename schemas, give each developer their own catalog in dev, while uat and prod keep shared catalogs:

# databricks.yml
variables:
  catalog:
    description: Catalog for this deployment.
    default: reporting

targets:
  dev:
    mode: development
    default: true
    experimental:
      skip_name_prefix_for_schema: true
    variables:
      catalog: dev_${workspace.current_user.short_name}
  uat:
    variables:
      catalog: uat_reporting
  prod:
    mode: production

Wait, did I not just tell you to avoid that flag? Here it is safe, and the catalog is the reason.

The flag removes the schema prefix, so the schema deploys as plain reporting. Normally that invites collisions. In this pattern it cannot, because Ana deploys only into dev_ana and Ben only into dev_ben. The private catalog does the isolating that the prefix would otherwise do.

Positives

Clean schema names and complete isolation at the same time.
Deterministic per-person catalogs make debugging and cleanup easy.
Works with existing code that expects fixed relative schema names.

Negatives

Each developer needs CREATE CATALOG on the metastore, or a platform script must pre-provision catalogs.
Catalogs accumulate. You need a naming convention and a cleanup habit.
Grants must be set per catalog, which is more governance surface to maintain.

Pick this pattern for teams that iterate fast on data products and want sandbox-per-developer ergonomics.

Choosing between them

Pattern	Stable names	Dev isolation	Extra infrastructure	Main risk
Accept the prefix	No, dynamic	Automatic	None	Code must be parameterised everywhere
Schemas outside DAB	Yes	Via separate tooling	Terraform or scripts	Drift between two sources of truth
Schema-only DAB	Yes	Single deployer identity	One more bundle and pipeline	Deployment ordering
Catalog per developer	Yes, within own catalog	Automatic	Privileges and cleanup habits	Catalog sprawl

My default recommendation: start with Pattern 1 while the team is small, and graduate to Pattern 3 once a platform function exists.

Reserve skip_name_prefix_for_schema for two cases only: bundles that exactly one identity will ever deploy, such as a CI-owned pipeline, and the isolated personal catalogs in Pattern 4. Never toggle it on a bundle that already manages data without a migration plan.

One warning that applies to all four patterns: switching between them renames schemas, and in a bundle a rename means delete and create. Migrate your data before you change approach.

Wrapping up

Treat schemas as a boundary decision, not an accident of YAML layout.

Accept the prefix and parameterise, move schemas to Terraform, give them a dedicated single-deployer bundle, or isolate at the catalog level.

Any of the four beats an afternoon of two engineers taking turns breaking each other's workspace.

Not sure where your bundle stands today? Run databricks bundle plan -t dev and look for schema resources. Then decide which side of the boundary you want them on.

Databricks Architecture Icons

Eduardo Rabelo — Mon, 10 Aug 2026 23:28:33 +0000

If you have ever tried to draw an architecture diagram that includes Databricks products, you know the drill.

You open the Databricks website, you right-click a hero image, you get a PNG at the wrong size, you give up and use a generic database cylinder.

The official artwork exists, it just is not packaged for the tools people actually diagram in.

So I packaged it:

https://oieduardorabelo.github.io/databricks-architecture-icons/

What it is

Databricks Architecture Icons is a community set of 71 products across 8 categories, ready for Mermaid, draw.io, Miro, Lucidchart, Excalidraw, Figma, Keynote and PowerPoint.

Every icon is an official Databricks SVG, nothing is redrawn or traced. A build script pulls each source file, fits it into a 48 by 48 canvas, and produces five variants of each product:

The plain vector
A mono version that follows the theme colour
A tile with a white glyph on the category colour
An outline in a white box with a lava hairline, so it works on both light and dark pages
A 256 pixel PNG for tools that reject SVG

It is unofficial. Databricks does not sponsor or endorse it. The artwork stays theirs.

Por que eu não uso bibliotecas de gerenciamento de estado no React

Eduardo Rabelo — Sat, 14 Dec 2024 01:18:44 +0000

Original source in English by Fabrizio Beccaceci
Why i no longer use a React state management library
https://medium.com/@ipla/why-i-no-longer-use-a-react-state-management-library-7bdffae54600

Índice

O que é uma Biblioteca de Gerenciamento de Estado Global?
Como o Redux Toolkit Resolve o Estado Global
As Duas Faces do Estado Global
A Abordagem Enxuta para Estado Global
- Para Estado do Servidor use TanStack Query
- Para Estado Compartilhado use Observables
Por que não usar React Context?
Conclusão

Quando comecei a aprender React anos atrs, havia duas coisas que voc precisava saber para se considerar um desenvolvedor React: TypeScript e Redux.

Hoje em dia, as coisas mudaram. Se voc est aprendendo React agora e se depara com o conceito de gerenciamento de estado, vai se sentir sobrecarregado com uma infinidade de bibliotecas: Redux, Redux Toolkit, MobX, Jotai, Zustand e a lista continua.

Mas antes de nos aprofundarmos, vamos responder pergunta bsica:

O que uma Biblioteca de Gerenciamento de Estado Global?

Mesmo se voc for relativamente novo no React, provavelmente sabe o que o termo estado. Voc cria um com o hook useState, e quando voc o atualiza, seu aplicativo renderiza novamente para refletir as mudanas.

No entanto, as coisas ficam complicadas quando voc precisa compartilhar alguma informao entre vrias partes no conectadas do seu aplicativo React.

Isso o que frequentemente chamamos de estado global , e o problema que as bibliotecas de gerenciamento de estado tentam resolver: como tornar o estado compartilhado acessvel a qualquer componente.

Vamos ver como o Redux Toolkit lida com isso.

Como o Redux Toolkit Resolve o Estado Global

Primeiro, voc cria uma store :

import { configureStore } from '@reduxjs/toolkit';

export const store = configureStore({
  reducer: {},
});

// Inferindo os tipos de RootState e AppDispatch usando a store
export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

Este o local central onde seu estado global ir existir. Em seguida, voc envolve seu aplicativo com um provider para tornar a store acessvel a todos os componentes:

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import App from './App';
import { store } from './app/store';

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
);

Agora, voc precisa definir os slices , que so partes individuais do seu estado global. Por exemplo:

import { createSlice } from '@reduxjs/toolkit';

interface CounterState {
  value: number;
}
const initialState: CounterState = { value: 0 };
export const counterSlice = createSlice({
  name: 'counter',
  initialState,
  reducers: {
    increment: (state) => { state.value += 1; },
    decrement: (state) => { state.value -= 1; },
    incrementByAmount: (state, action) => {
      state.value += action.payload;
    },
  },
});
export const { increment, decrement, incrementByAmount } = counterSlice.actions;
export default counterSlice.reducer;

Por fim, voc conecta este slicestore:

import { configureStore } from '@reduxjs/toolkit';
import counterReducer from './features/counter/counterSlice';

export const store = configureStore({
  reducer: { counter: counterReducer },
});

Neste ponto, voc pode usar seu estado global nos componentes da seguinte forma:

import React from 'react';
import { useSelector, useDispatch } from 'react-redux';
import { increment, decrement } from './counterSlice';

export function Counter() {
  const count = useSelector((state) => state.counter.value);
  const dispatch = useDispatch();
  return (
    <div>
      <button onClick={() => dispatch(increment())}>Increment</button>
      <span>{count}</span>
      <button onClick={() => dispatch(decrement())}>Decrement</button>
    </div>
  );
}

Embora o Redux Toolkit simplifique significativamente o Redux, ainda tem muito cdigo boilerplate para o que geralmente uma necessidade simples. E nem sequer falamos sobre aes assncronas como requisies ao servidor!

Alm disso, muitos iniciantes caem na armadilha de colocar todo o seu estado no Redux, levando a stores globais infladas que so mais difceis de gerenciar.

As Duas Faces do Estado Global

Quando voc para pra pensar, a maioria do "estado global" se enquadra em duas categorias:

Estado do Servidor : Dados obtidos de um servidor, como uma lista de clientes em um aplicativo CRM.
Estado da UI Compartilhado : Pequenos pedaos de dados necessrios em vrios lugares, como o usurio atualmente logado.

Vamos abordar cada um deles separadamente.

A Abordagem Enxuta para Estado Global

Com ferramentas modernas, voc pode lidar com estado global sem uma biblioteca dedicada de gerenciamento de estado:

1. Para Estado do Servidor use TanStack Query

TanStack Query (anteriormente React Query) feito especificamente para gerenciar estado do servidor. Ele lida com cache, recarregamento, dados obsoletos e muito mais, tudo pronto para uso, e voc definitivamente deveria usar isso porque voc realmente no vai querer reimplementar tudo isso do zero. Por exemplo, buscar uma lista de clientes to simples quanto:

import { useQuery } from '@tanstack/react-query';

function Customers() {
  const { data, error, isLoading } = useQuery(['customers'], fetchCustomers);
  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error: {error.message}</div>;
  return <ul>{data.map((customer) => <li key={customer.id}>{customer.name}</li>)}</ul>;
}

O TanStack Query elimina a necessidade de gerenciar manualmente o estado do servidor e, como o estado que voc busca armazenado em cache, voc pode us-lo exatamente da mesma maneira em todos os componentes e ele ser buscado apenas uma vez.

2. Para Estado Compartilhado use Observables

Para estados menores e especficos do aplicativo, como o usurio logado, eu uso uma implementao leve do padro Observable :

export class Observable<T> {
  private _value: T;
  private subscribers = new Set<(value: T) => void>();

  constructor(initialValue: T) {
      this._value = initialValue;
    }
    get value() {
      return this._value;
    }
    set value(newValue: T) {
      this._value = newValue;
      this.notify();
    }
    subscribe(callback: (value: T) => void) {
      this.subscribers.add(callback);
      callback(this._value);
      return { unsubscribe: () => this.subscribers.delete(callback) };
    }
    private notify() {
      this.subscribers.forEach((callback) => callback(this._value));
    }
  }
}

Com isso, voc pode conectar Observables ao React usando useSyncExternalStore:

import { useSyncExternalStore } from 'react';

export function useObservable<T>(observable: Observable<T>) {
  return useSyncExternalStore(
    (callback) => observable.subscribe(callback).unsubscribe,
    () => observable.value
  );
}

Agora, voc pode criar e usar observables desta forma:

const loggedUser = new Observable<User>(user);

loggedUser.value // Para acessar o valor dentro do Observable fora do React

loggedUser.value = someOtherUser // Para definir o valor, tanto fora quanto dentro do React

Dentro de um componente React:

const user = useObservable(loggedUser);

Por que no usar React Context?

Embora o React Context funcione em alguns casos, ele tem desvantagens:

Escopo Limitado : Voc no pode acessar o Context fora dos componentes React.
Problemas de Performance : Context dispara uma nova renderizao para todos os componentes abaixo dele, at mesmo para os componentes que no usem o valor atualizado.

Usando Observables evitamos ambos problemas!

Concluso

Gerenciamento de estado global no precisa ser complicado. Combinando TanStack Query e um padro Observable leve, voc pode simplificar seu aplicativo evitando as armadilhas das bibliotecas tradicionais de gerenciamento de estado.

Entre em contato comigo se quiser discutir sobre React, React Native, Nextjs

Me contate no X (antigo Twitter)
Ou acesse Iplastudio

Bom desenvolvimento! 🎉

S3 virus scanning with TypeScript and Node.js 20.x AWS Lambda Container

Eduardo Rabelo — Wed, 06 Dec 2023 05:06:45 +0000

Searching the internet, you can find guides showing how to create a serverless virus scanning with ClamAV:

Even in the AWS Blog you can find good ideas:

However, a few aspects fell short of my expectations:

1) They are not using the latest version of ClamAV
The examples above are installing ClamAV directly from the OS package registry (e.g., yum install clamav).

They aren't always in sync with the latest release, and if you don't update or upgrade the OS package registry, you will install older versions.

Using yum install clamav for Amazon Linux 2, we receive the 0.100.x version, whereas the ClamAV release is already in the 1.x version.

2) Outdated Node.js runtime
Examples using Node.js use the outdated Node.js 14.x runtime. This runtime is already under Deprecation (Phase 1) in the AWS timeline for Node.js supported runtimes and is not part of the maintenance window of Node.js releases.

Using outdated and unsupported versions is a risk I try to avoid!

3) Using plain JavaScript
While not a deal-breaker, I don't use plain JavaScript in my production projects.

How would a TypeScript example look in the latest AWS Lambda runtime for Node.js?

4) How to use top-level await in Node.js handlers
Top-level await support in AWS Lambda is not new, but how can we configure it with everything else? (e.g., TypeScript, esbuild, etc). How can we output ESM code in the lambda handler?

Here it comes Amazon Linux 2023

Starting on Node.js 20.x runtime, the default operational system for the AWS Lambda base image is Amazon Linux 2023.

The AL2023 brings a new package management tool called dnf.

dnf is the successor to yum, the package management tool in Amazon Linux 2.

While many of the commands are compatible, for example, for the following Amazon Linux 2 yum commands:

$ sudo yum install packagename
$ sudo yum search packagename
$ sudo yum remove packagename

In AL2023, they become these commands:

$ sudo dnf install packagename
$ sudo dnf search packagename
$ sudo dnf remove packagename

Not everything stays the same. Be aware of changes! 🚨

You can check the page changes in dnf CLI compared to yum.

Let's build a newer example

We'll keep the example project similar to the guides listed at the beginning:

A S3 bucket with object notification to an AWS Lambda
When an object is created in S3, a notification triggers the AWS Lambda
The Lambda will read the file from the bucket, write it to /tmp, and run clamscan on it
The returned code from clamscan will be used to check the file status

There are a few constraints I want to define for our newer example:

Because we need to download the ClamAV virus database in our lambda source code, the uncompressed file size of 250MB can be an issue.
We will be using AWS Lambda Container image code, which enables us to have up to 10GB of uncompressed image size.
The Docker build process should take care of transpiling TypeScript to JavaScript and installing production-only dependencies.
We want to download and install the latest ClamAV during the Docker build process and update its virus definitions.

The Dockerfile

We can use Docker multi-stage builds to create these steps:

# ========================================
# Builder Image
# ========================================
FROM --platform=linux/x86_64 public.ecr.aws/lambda/nodejs:20 as builder

COPY package.json package-lock.json index.ts  ./

#
# 1) install dependencies with dev dependencies
# 2) build the project
# 3) remove dev dependencies
# 4) install dependencies without dev dependencies
#
RUN npm install && \
    npm run build && \
    rm -rf node_modules && \
    npm install --omit=dev

# ========================================
# Runtime Image
# ========================================
FROM --platform=linux/x86_64 public.ecr.aws/lambda/nodejs:20 as runtime

ENV CLAMAV_PKG=clamav-1.2.1.linux.x86_64.rpm
RUN <<-EOF
    set -ex

    #
    # install glibc-langpack-en to support english language and utf-8
    # this was required by clamscan to avoid error "WARNING: Failed to set locale"
    #
    dnf install wget glibc-langpack-en -y

    # 
    # 1) download latest ClamAV from https://www.clamav.net/downloads
    # 2) install using `rpm` and it requires full path for local packages
    # 3) remove the downloaded package and clean up for smaller runtime image
    # 
    wget https://www.clamav.net/downloads/production/${CLAMAV_PKG}
    rpm -ivh "${LAMBDA_TASK_ROOT}/${CLAMAV_PKG}"
    rm -rf ${CLAMAV_PKG}
    dnf remove wget -y
    dnf clean all

    #
    # the current working directory is "/var/task" as defined in the base image:
    # https://github.com/aws/aws-lambda-base-images/blob/nodejs20.x/Dockerfile.nodejs20.x
    #
    # 1) "lib/database" is the path to download the virus database
    # 2) "freshclam.download.log" and "freshclam.conf.log" are the log files for freshclam CLI
    #
    mkdir -p ${LAMBDA_TASK_ROOT}/lib/database
    touch ${LAMBDA_TASK_ROOT}/lib/{freshclam.download.log,freshclam.conf.log}
    chmod -R 777 ${LAMBDA_TASK_ROOT}/lib

    #
    # default configuration path for freshclam is "/usr/local/etc/freshclam.conf"
    # we create a symbolic link to the default configuration path and copy our custom config file
    #
    ln -s /usr/local/etc/freshclam.conf ${LAMBDA_TASK_ROOT}/lib/freshclam.conf
EOF

COPY freshclam.conf /var/task/lib/freshclam.conf

#
# freshclam CLI is a virus database update tool for ClamAV, documentation:
# https://linux.die.net/man/1/freshclam
#
RUN <<-EOF
    set -ex
    export LOG_FILE_PATH="${LAMBDA_TASK_ROOT}/lib/freshclam.conf.log"

    freshclam --verbose --stdout --user root \
        --log=${LOG_FILE_PATH} \
        --datadir=${LAMBDA_TASK_ROOT}/lib/database

    if grep -q "Can't download daily.cvd\|Can't download main.cvd\|Can't download bytecode.cvd" ${LOG_FILE_PATH}; then
        echo "ERROR: Unable to download ClamAV database files - your request may be being rate limited"
        exit 1;
    fi
EOF

#
# copy application files from the builder image
# 
COPY --from=builder /var/task/dist/* /var/task/
COPY --from=builder /var/task/node_modules /var/task/node_modules

CMD [ "index.handler" ]

The above Dockerfile covers:

Install and build the TypeScript Lambda to JavaScript with production dependencies using a multi-stage build. The first stage as builder creates the dist folder and node_modules folder used by the as runtime stage
Download the latest ClamAV from their release page, install it using rpm and remove cache for smaller final image
Download the ClamAV virus database definitions with freshclam
You can change the CLAMAV_PKG to be in sync with the latest version of ClamAV

🚨 Important: To update your database definition, you need to re-build this image every once in a while

The required freshclam.conf file contains the following:

CompressLocalDatabase yes
DatabaseDirectory /var/task/lib/database
DatabaseMirror database.clamav.net
DNSDatabaseInfo current.cvd.clamav.net
ScriptedUpdates no
UpdateLogFile  /var/task/lib/freshclam.conf.log

🚨 Important: The full path files (e.g., /var/task/* must match the Dockerfile definitions

The TypeScript AWS Lambda Handler

For a S3 notification event, we can write our handler similar to:

import { S3CreateEvent } from "aws-lambda";
import { GetObjectCommand, S3Client } from "@aws-sdk/client-s3";
import { spawnSync } from "node:child_process";
import { mkdir, writeFile } from "node:fs/promises";

const s3Client = await new S3Client({});

//
// directories for clamscan
// "/tmp/files_to_scan" where we will store the files from s3 to scan
// "/tmp/clamscan_tmp" required by clamscan to store temporary files during the virus scan
//
await mkdir("/tmp/files_to_scan", { recursive: true });
await mkdir("/tmp/clamscan_tmp", { recursive: true });

async function handler(event: S3CreateEvent) {
  console.log(JSON.stringify(event, null, 2));

  for (const record of event.Records) {
    const bucketName = record.s3.bucket.name;
    const objectKey = record.s3.object.key;

    const getObjectCommand = new GetObjectCommand({
      Bucket: bucketName,
      Key: objectKey,
    });
    const s3Object = await s3Client.send(getObjectCommand);
    const s3ObjectContent = (await s3Object.Body?.transformToString()) as string;

    const tmpFilePath = `/tmp/files_to_scan/${objectKey}`;
    await writeFile(tmpFilePath, s3ObjectContent, { encoding: "utf-8" });

    //
    // clamscan CLI documentation:
    // https://linux.die.net/man/1/clamscan
    //
    const clamavScan = spawnSync(
      "clamscan",
      ["--verbose", "--stdout", `--database=/var/task/lib/database`, `--tempdir=/tmp/clamscan_tmp`, tmpFilePath],
      {
        encoding: "utf-8",
        stdio: "pipe",
      },
    );
    console.log(JSON.stringify(clamavScan, null, 2));

    // You can find the return codes here:
    // https://linux.die.net/man/1/clamscan
    if (clamavScan.status === 0) {
      console.log("no virus found");
    } else if (clamavScan.status === 1) {
      console.log("virus found");
    } else if (clamavScan.status === 2) {
      console.log("some error(s) occured in clamscan");
    }

    await unlink(tmpFilePath);
  }
}

export { handler };

We use the top-level await feature and create two folders when the lambda container starts.

Later, we use spawnSync to trigger the clamscan binary installed via the Dockerfile.

Ensure you use full path definitions in the clamscan parameters, for example: /var/task/lib/database, to load the correct virus definitions.

We can test the ClamAV detection using any EICAR text files. The result should look like:

Now, we have our Dockerfile, ClamAV configuration, and Lambda handler.

Where do we deploy all of that?

The CDK TypeScript Project

Because Docker is building our lambda handler, we create its own package.json with dependencies:

{
  "name": "clamav-scan",
  "version": "1.0.0",
  "type": "module",
  "scripts": {
    "build": "rimraf dist && esbuild index.ts --format=esm --outfile=dist/index.mjs"
  },
  "devDependencies": {
    "@types/aws-lambda": "^8.10.130",
    "esbuild": "^0.19.8",
    "rimraf": "^5.0.5",
    "typescript": "^5.3.2"
  },
  "dependencies": {
    "@aws-sdk/client-s3": "^3.465.0"
  }
}

Using "type": "module" will tell TypeScript and Node.js that we are aiming to use ECMAScript Modules in our source code (ESM).

The build command asks esbuild to output our source code in the ESM format with the --format=esm flag.

The last piece of the puzzle, is the tsconfig.json:

{
  "compilerOptions": {
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "isolatedModules": true,
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "noEmit": true,
    "preserveConstEnums": true,
    "skipLibCheck": true,
    "sourceMap": false,
    "strict": true,
    "target": "ESNext"
  },
  "exclude": ["node_modules"]
}

Using NodeNext for moduleResolution / module and ESNext for target, will tell the TypeScript engine tsc to output code in ESM format.

The complete example can be found on GitHub:

oieduardorabelo / s3-virus-scanning-typescript-aws-lambda-container

S3 virus scanning with TypeScript and Node.js 20.x AWS Lambda Container

ClamAV 1.2.1 with AWS Lambda Container Images for Node.js 20.x

CDK project for deploying a ClamAV 1.2.1 with AWS Lambda Container Images for Node.js 20.x

This helps you to scan files for viruses using AWS Lambda functions

🚨 Important:

Virus definitions are updated during build
Ensure you are building the container regularly to keep your definitions up to date
You can update the Dockerfile to use a different version of ClamAV

View on GitHub

🚨 WARNING: You are being rate-limited

This is super important and caught me off guard multiple times.

Pay attention to the number of viruses your database is using:

During the build process of your Docker image, the ClamAV database mirror can rate limit your IP address and block you from downloading the virus definitions.

For example, visiting to https://database.clamav.net/main.cvd, can return the following:

Ensure your freshclam is downloading and loading the definitions:

daily.cvd

main.cvd

and bytecode.cvd

By default freshclam CLI will NOT throw an error when that happens.

That's why in the Dockerfile we are grepping the log file generated by the CLI and looking for errors:

    if grep -q "Can't download daily.cvd\|Can't download main.cvd\|Can't download bytecode.cvd" ${LOG_FILE_PATH}; then
        echo "ERROR: Unable to download ClamAV database files - your request may be being rate limited"
        exit 1;
    fi

And we manually throw an error when any of the rate-limiting messages are detected! 🏁

Understanding AWS CloudFormation Execution Permissions

Eduardo Rabelo — Mon, 17 Jul 2023 09:51:12 +0000

Do you know how CloudFormation generates permissions to provision resources in your account?

In my new article on the AWS Fundamentals blog, we walk through the CloudFormation lifecycle and how you can apply security concepts like the least privileged access in the deployment of your stack.

https://blog.awsfundamentals.com/aws-cloudformation-execution-permissions

AWS IAM Roles with AWS CloudFormation

Eduardo Rabelo — Sun, 09 Jul 2023 22:20:18 +0000

If you are starting with CloudFormation and IAM Roles, I wrote an introductory article on the AWS Fundamentals blog:

https://blog.awsfundamentals.com/aws-iam-roles-with-aws-cloudformation

If you enjoyed this post & you want to get 𝗯𝗶𝘁𝗲-𝘀𝗶𝘇𝗲𝗱 𝗔𝗪𝗦 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 straight to your inbox, feel free to check out our bi-weekly newsletter 📨

You can also browse our 𝗽𝗿𝗲𝘃𝗶𝗼𝘂𝘀 𝗶𝘀𝘀𝘂𝗲𝘀 to see what you'll subscribe to 📚

https://newsletter.awsfundamentals.com/

Parte 03 - Maximize a economia de custos e escalabilidade do DynamoDB com índice secundário otimizado

Eduardo Rabelo — Wed, 12 Apr 2023 11:34:13 +0000

Créditos

Escrito originalmente por Pete Naylor, em Maximize cost savings and scalability with an optimized DynamoDB secondary index.

Entenda projeções e medição de dados. Esqueça a sobrecarga de GSI.

Esta é a terceira parte de uma série de artigos sobre modelagem de dados do DynamoDB, criada principalmente para ajudar os desenvolvedores usando DynamoDB a entender as práticas recomendadas e evitar seguir um caminho lamentável com técnicas equivocadas de "design de tabela única". No episódio anterior - isso é um show agora? - introduzimos índices secundários locais e globais (LSIs e GSIs).

Hoje, vamos nos aprofundar para entender quais dados da tabela são projetados em um índice secundário e como isso contribui para o consumo de taxa de transferência. Também vamos separar uma das reviravoltas mais recentes no "design de tabela única" — sobrecarga de GSI — e explicar por que geralmente é uma péssima ideia sem nenhum lado positivo real. Preparado? Lá vamos nós!

Quais mudanças na tabela base são relevantes para projeção em um índice secundário?

Ao definir um índice secundário, você pode escolher quais atributos serão copiados (projetados) das alterações de itens relevantes na tabela base:

ALL — todos os atributos no item da tabela base serão copiados para o índice secundário
INCLUDE — somente a lista nomeada de atributos será copiada (e também os atributos de chave primária da tabela base e o índice secundário — estes são sempre incluídos)
KEYS_ONLY — somente os atributos de chave primária da tabela base e o índice secundário serão copiados

É assim que a medição funciona para índices secundários do DynamoDB: cada gravação feita em sua tabela base será considerada para a projeção de dados em cada um de seus índices secundários. Se a alteração do item na tabela base for relevante para o índice secundário, ela será projetada e haverá consumo da unidade de gravação - medido de acordo com o tamanho do item projetado. Haverá um custo de armazenamento para os dados projetados no índice secundário também. E lembre-se, conforme explicado no primeiro artigo desta série, Query e Scan (as únicas operações de leitura disponíveis para índices secundários) agregam o tamanho de todos os itens e, em seguida, arredondam para cima, para avaliar o total da medição da unidade de leitura. Se você mantiver a projeção de seus itens pequena, o índice custará menos e será dimensionado ainda mais antes de enfrentar qualquer tipo de preocupação importante.

Considere a projeção com muito cuidado para seu índice secundário. ALL parece simples, mas pode ser muito caro e pode inibir a escalabilidade de seu design em geral. Projete apenas os atributos que você realmente precisa.

Há mais detalhes nesta equação de eficiência para índices secundários. Você provavelmente está se perguntando por que continuo enfatizando a palavra relevante . Bem, é porque é realmente importante! Primeiro, como o DynamoDB oferece flexibilidade de esquema, os atributos definidos como a chave para seu índice secundário não precisam estar presentes em todos os itens de sua tabela (a menos que façam parte da chave primária dessa tabela). Se os atributos da chave do índice não estiverem presentes em um item da tabela, ele não será considerado relevante para projeção no índice. Você pode usar isso para criar um "índice esparso" — um poderoso mecanismo de filtragem — para localizar os dados necessários com o menor custo de armazenamento e taxa de transferência.

Um exemplo pode ser um banco de dados que armazena detalhes de status de milhões de tarefas - a grande maioria delas sendo concluída. Como podemos tornar as busca de tarefas que estão no status "enviado" mais fácil? Para tarefas que estão no status relevante da busca ("enviado"), crie um atributo que indique isso e adicione um índice secundário que seja definido por esse atributo. A presença do atributo efetivamente se torna um sinalizador - quando a tarefa for concluída, remova este atributo - a tarefa não estará mais visível no índice secundário quando a busca for realizada.

[Nossa tabela base que rastreia o status da tarefa]

[Índice secundário esparso que contém apenas tarefas aguardando atribuição]

Agora vamos imaginar que, como parte do fluxo de trabalho para tarefas com status enviado, o item de tarefa na tabela seja atualizado cinco vezes para adicionar vários detalhes em atributos não-chave. Se esses atributos forem projetados para nosso índice secundário esparso de tarefas enviadas, o índice também precisará ser atualizado cinco vezes, consumindo várias unidades de gravação. Mas nosso índice secundário esparso realmente não tem utilidade para esses atributos - eles não são relevantes para o padrão de acesso que precisamos que o índice atenda. Portanto, escolhemos uma projeção KEYS_ONLY para o índice — ela mantém baixo o consumo de unidade de leitura, maximiza a escalabilidade de busca de tarefas, economiza dinheiro em armazenamento e evita várias gravações desnecessárias na projeção do índice.

[O mesmo índice secundário, agora esparso com projeção KEYS_ONLY. Muito mais eficiente!]

O que é "sobrecarga de GSI" e por que é uma má ideia?

Em 2017, as equipes da Amazon estavam trabalhando duro para migrar suas cargas de trabalho mais críticas de bancos de dados relacionais para o DynamoDB. Eles estavam aprendendo a pensar de maneira diferente sobre a modelagem de dados, olhando além da familiar terceira forma normal (3FN) e desnormalizando dados em itens e coleções de itens no DynamoDB. Naquela época, o DynamoDB suportava no máximo 5 GSIs por tabela, limite máximo. Em alguns casos raros, haveria uma equipe com uma tabela que exigia mais de 5 GSIs para cobrir todos os seus padrões de acesso. Para aqueles de nós que trabalham para dar suporte a essas equipes, percebemos que algumas das necessidades de índice podem ser esparsas e não se sobrepõem. Talvez com alguma adaptação instável pudéssemos usar o mesmo GSI para cobrir vários requisitos de padrão de acesso - isso poderia nos ajudar a trapacear no limite do GSI? Sim: era o último recurso, tinha implicações terríveis de eficiência e operabilidade - mas às vezes funcionava. Nós nos referimos a isso como "sobrecarga de GSI".

Avançando para dezembro de 2018, o DynamoDB aumentou o limite de GSIs por tabela para 20. Alegria! Não há necessidade do hack feio de sobrecarga a partir de agora... certo? Bem, a equipe de engenharia pensou que sim, mas então surgiram algumas reviravoltas perturbadoras na fábula do "design de tabela única".

Acontece que, se você fizer coisas não naturais, desnecessárias, complexas e ineficientes para enviar dados completamente não relacionados para apenas uma tabela do DynamoDB sem motivo, acabará tendo que criar mais índices secundários para essa tabela.

Se você estiver projetando dados com o objetivo de ter exatamente uma tabela (em vez de priorizar eficiência, flexibilidade e escalabilidade), é mais provável que você encontre o limite de GSIs por tabela - e então a mesma obsessão de "exatamente uma tabela" gere um desejo equivocado ter exatamente um GSI, o que leva à sobrecarga. Isso cria uma série de problemas. Na verdade, essa técnica não traz nenhum benefício — é uma má ideia. Aqui está o porquê:

Você provavelmente precisará fazer compensações para a projeção de dados que lhe custará dinheiro e prejudicará a escalabilidade do seu design. O menor denominador comum é projetar ALL e padronizar strings para atributos de chave primária (quando números seriam mais eficientes). Ai!
Você perde a flexibilidade de poder varrer o índice secundário e recuperar apenas os dados de seu interesse. Essa é uma funcionalidade poderosa que se foi - sem nenhum motivo.
Uma das grandes vantagens dos GSIs é que você pode excluí-los e recriá-los conforme necessário. Excluir um GSI não custa nada. Se você misturou vários requisitos de índice em um único GSI e em algum momento percebeu que não precisa indexar um de seus padrões, você não pode simplesmente excluir esse GSI. Você terá que (cuidadosamente) voltar para o design da sua tabela e fazer atualizações em massa relativamente caras (e potencialmente arriscadas). Você realmente não quer lidar com isso.

Lições importantes

Resumindo, não há benefício na "sobrecarga de GSI" – apenas pontos negativos. Não faça isso! Além disso, se você se preocupa com a otimização de custos e a escalabilidade, considere a dispersão e a projeção mínima ao projetar índices secundários no DynamoDB.

No próximo artigo desta série, pretendo desenvolver o que aprendemos até agora para explicar onde as coisas deram errado com o "design de tabela única" e por que interpretá-lo exatamente como uma tabela é um erro terrível (que as equipes da Amazon não estão fazendo).

Se você quiser discutir esse tópico comigo, obter minha opinião sobre uma pergunta de modelagem de dados do DynamoDB que você tem ou sugerir tópicos para eu escrever em artigos futuros, entre em contato comigo no Twitter (@pj_naylor) ou envie-me um [e-mail diretamente]mailto:petenaylor@momentohq.com)!

Parte 02 - Qual tipo de índice secundário do DynamoDB você deve escolher?

Eduardo Rabelo — Wed, 12 Apr 2023 11:21:47 +0000

Créditos

Escrito originalmente por Pete Naylor, em Which flavor of DynamoDB secondary index should you pick?.

Use o poder dos índices secundários locais e globais.

Este é o segundo artigo de uma série curta sobre modelagem de dados no Amazon DynamoDB (sem os equívocos de "design de tabela única"). Se você não leu o primeiro artigo, eu o encorajo a dar uma olhada. Nele, discuto os conceitos mais importantes da modelagem do DynamoDB: flexibilidade de esquema e coleções de itens. Vou us essa base para discutir índices secundários, um dos meus recursos favoritos do DynamoDB. Observe que este artigo assume alguma familiaridade com os principais conceitos do DynamoDB, como partições, itens, tipos de chave primária e tipos de dados. Se você precisa se atualizar sobre eles, aqui está uma lista de vídeos que eu recomendo.

Índices secundários são poderosos! Você pode usá-los para fornecer automaticamente diferentes perspectivas para leituras dos dados em sua tabela. Eles ajudam você a definir e manter relacionamentos adicionais (coleções de itens) dentro dos mesmos dados, permitem que você classifique os dados relacionados com uma dimensão diferente e podem criar filtros incrivelmente eficazes.

Mas, como qualquer outra ferramenta, é possível utilizar os índices secundários do DynamoDB de um modo ruim.

Com grandes poderes vêm grandes responsabilidades - e uma grande necessidade de entender suas opções! Neste blog, vou me concentrar em comparar os diferentes tipos de índices secundários e oferecer algumas dicas para escolher entre eles. Deixarei de falar sobre escolhas de projeção de índice secundário e as consequências de custo e escalabilidade para o próximo artigo, além de algumas observações sobre uma tendência recente no uso de índices secundários globais do DynamoDB chamada "sobrecarga" (overloading) e por que ela deve ser evitada no design das suas tabelas na maioria dos casos.

Então fique ligado! E segurem seus chapéus - será uma turnê alucinante.

Onde vivem os índices secundários? E como eles chegam lá?

Os dados de sua tabela (o índice primário) são projetados em cseus índies secundários pelo DynamoDB com base na definição de índice que você fornece. Você não pode escrever diretamente em um índice secundário, mas ao escrever em um item em sua tabela base, o DynamoDB projetará alterações relevantes em seus índices secundários para você. Existem dois tipos de índice secundário: índices secundários locais (LSIs - Local Secondary Indexes) e índices secundários globais (GSIs - Global Secondary Indexes).

Índices secundários locais

Os LSIs residem nas mesmas partições do DynamoDB que a tabela base — eles compartilham o mesmo atributo de chave de partição (mas têm um atributo de chave de classificação diferente) e compartilham a taxa de transferência com a tabela base. Os LSIs são locais porque oferecem uma ordem de classificação diferente para uma coleção de itens dentro da mesma partição. Os LSIs oferecem suporte a leituras fortemente consistentes após escrever na tabela base, se o parâmetro for especificado na hora da solicitação de dados (caso contrário, a consistência eventual padrão é usada).

Na verdade, os LSIs e as tabelas base compartilham as mesmas coleções de itens — e isso restringe cada coleção de itens a residir em uma única partição. Quando uma tabela tem um ou mais LSIs, cada coleção de itens nunca pode crescer além de aproximadamente 10 GB (todos os dados para o mesmo valor da chave de partição na tabela base e todos os LSIs combinados). A taxa de transferência de leitura e escrita para qualquer coleção de itens é limitada a 3.000 unidades de leitura por segundo e 1.000 unidades de escrita por segundo na tabela e todos os LSIs associados.

Os LSIs devem ser definidos quando a tabela é criada e não podem ser excluídos sem excluir a tabela base associada. Pense bem antes de usar LSIs em seu modelo de dados - você deve ter um bom motivo (como um requisito válido para leituras fortemente consistentes) e deve saber que nunca terá uma coleção de itens que possa crescer e exigir mais de 10 GB, 3.000 unidades de leitura por segundo ou 1.000 unidades de escrita por segundo.

Se você decidir posteriormente que não quer ser limitado pelas propriedades dos LSIs ou não precisa mais de um LSI específico, pode ser necessária uma migração complexa de sua existente tabela para uma tabela de substituição/nova tabela.

Índices secundários globais

Os GSIs são como uma tabela separada — eles podem ter um atributo de chave de partição diferente e têm suas próprias partições e capacidade de taxa de transferência. Eles podem ser criados (com preenchimento/with backfill) conforme necessário e removidos (sem custo) quando não forem mais necessários. Eles são globais porque permitem que novos relacionamentos (coleções de itens) sejam definidos entre itens em todas as partições da tabela base. As coleções de itens em um GSI podem abranger partições para armazenar mais dados e fornecer maior taxa de transferência (também verdadeiro para a tabela base, desde que não haja LSIs).

Uma das maiores diferenças entre LSIs e GSIs está em seu comportamento durante a escrita na tabela base. Como a tabela base e quaisquer LSIs compartilham as mesmas partições, quaisquer atualizações nos LSIs são manipuladas atomicamente com a alteração no item da tabela base. Para GSIs, a alteração é propagada de forma assíncrona para uma partição diferente. Isso tem implicações de consistência de leitura após escrita. As leituras de um LSI podem ser solicitadas para serem consistentes, se desejado, mas uma leitura de um GSI é sempre eventualmente consistente.

Uma consideração adicional para leituras de um GSI é a monotonicidade. As leituras GSI não são monotônicas. Se você atualizar um item em sua tabela base para incrementar o valor de um atributo de 7 para 8, poderá fazer três leituras sucessivas dos dados projetados em seu GSI e ver o valor como 8 primeiro, depois 7 e, finalmente, de volta para 8. Uma série de leituras para os mesmos dados em um GSI pode retornar resultados que avançam e retrocedem ao longo do tempo. As leituras fortemente consistentes da tabela ou de um LSI são monotônicas.

Os GSIs são mais flexíveis que os LSIs, e qualquer LSI pode ser facilmente modelado como um GSI. Use LSIs apenas se tiver certeza de que o índice precisará suportar leituras consistentes/monotônicas ou se quiser se beneficiar do recurso de "leitura completa" (read through) (detalhes sobre isso em um artigo futuro).

Propriedades interessantes de chaves de índice secundárias

Em primeiro lugar: o valor da chave de índice não é garantido como único, como a chave primária em sua tabela base. O índice pode ter várias entradas projetadas com os mesmos valores para a chave de partição do índice e a chave de ordenação! A API GetItem não tem suporte para índices secundários porque GetItem implica a leitura de no máximo um item para um determinado valor da chave. Mas em um índice secundário, mesmo quando um valor específico da chave de índice é fornecido, você pode ver muitos itens retornados! Você deve usar Query ou Scan para ler de um LSI ou GSI. LSIs fornecem uma ordenação alternativa (sort key), GSIs fornecem coleções alternativas e ordenação (opcional).

Conforme mencionado anteriormente, um LSI deve ter uma chave composta. A tabela base à qual o LSI está anexado também deve ter uma chave composta. A chave de partição do LSI deve ser a mesma da tabela base e o atributo da chave de ordenação deve ser diferente daquele da tabela. Um exemplo simples pode ser uma interface do usuário que lista um conjunto de entradas em formato tabular — as entradas são agrupadas (coleções de itens relacionadas pelo mesmo valor do atributo chave de partição) e ordenadas por um dos valores de seus atributos (a chave de ordenação da tabela base). E se o usuário precisar ordenar o mesmo grupo de entradas por um atributo diferente? É aqui que um LSI pode ajudá-lo.

GSIs são mais flexíveis: uma chave de partição é necessária, mas pode ser diferente da tabela base - você pode relacionar/agrupar os dados da sua tabela em um atributo diferente! Uma GSI pode ter uma chave simples ou uma chave composta — e o mesmo vale para a tabela base à qual está anexada. Se você não precisa recuperar coleções de itens de seu GSI ordenados (talvez o padrão seja apenas consultar todos os itens que têm um valor comum de chave de partição no índice), não defina uma chave de ordenação - a GSI ainda pode construir coleções de itens para uma busca de dados eficiente. Definir uma chave de ordenação quando não é necessário pode limitar sua escalabilidade para as coleções de itens.

Detalhando distinções entre tipos de índices secundários

Há muitas nuâncias aqui, mas na verdade se resumem a algumas diferenças simples, então fiz uma folha de dicas que você pode usar na próxima vez que estiver considerando suas opções de índice secundário.

Fique de olho no próximo artigo desta série de modelagem de dados do DynamoDB (que visa detalhar o "design de tabela única").

Em artigos futuros: mais sobre indexação secundária e uma discussão resumida sobre onde o "design de tabela única" deu terrivelmente errado.

Parte 01 - O que realmente importa na modelagem de dados do DynamoDB?

Eduardo Rabelo — Wed, 12 Apr 2023 11:07:54 +0000

Créditos

Escrito originalmente por Pete Naylor, em What really matters in DynamoDB data modeling?.

Spoiler: não é o número de tabelas!

Quando deixei a equipe do DynamoDB alguns meses atrás, decidi que precisava compartilhar o que aprendi sobre como modelar dados para o DynamoDB e operá-lo bem. Durante meus seis anos trabalhando com clientes internos e externos do DynamoDB na AWS, tive a sorte de obter exposição a uma ampla variedade de modelos de dados do DynamoDB. Eu também vi como eles evoluíram na operação: como eles foram dimensionados (ou não) utilização com carga variável, sua flexibilidade para acomodar novos requisitos de aplicativos e se eles se tornaram proibitivos em termos de custo ao longo do tempo.

Esta é a primeira parte de uma pequena série de artigos que publicarei com o objetivo de corrigir alguns equívocos sobre as práticas recomendadas de modelagem de dados do DynamoDB. Nos últimos anos, recomendações estranhas evoluíram por meio dos rumores das mídias sociais (com a ajuda do marketing da AWS). Vou escrever sobre o mundo real. Darei os mesmos conselhos que a equipe do DynamoDB dá a outras equipes da Amazon para quem o serviço é de missão crítica - as mesmas recomendações de otimização, os mesmos avisos sobre o placebo do "design de tabela única", as mesmas dicas sobre a interpretação de métricas, os mesmos detalhes nas nuâncias de mensuração e medição, e o mesmo foco na excelência operacional.

Pronto para começar? Nesse primeiro artigo, definirei as bases para a série, compartilhando o molho secreto para o sucesso com o DynamoDB. Reconheço que demorei um pouco para realmente grocar essas coisas. Me siga! Eu conheço alguns atalhos.

O que realmente importa se não é tudo sobre o número de tabelas?

Os dois primeiros conceitos que você precisa entender ao aprender modelagem de dados do DynamoDB para levar seu pensamento além dos casos de uso de chave-valor simples são:

Flexibilidade de Esquema
Coleções de itens

Flexibilidade de esquema significa que nem todos os itens em uma tabela do DynamoDB exigem a mesma estrutura – cada item pode ter seu próprio conjunto de atributos e tipos de dados – isso abre muitas possibilidades! Na verdade, os únicos atributos para os quais o esquema é obrigatório são os atributos de chave primária — aqueles usados para indexar os dados na tabela. Cada item deve incluir os atributos-chave definidos para a tabela com o tipo de dados correto.

Uma coleção de itens é o conjunto de todos os itens que possuem o mesmo valor de atributo que a chave de partição; em outras palavras, eles estão todos relacionados pelo valor da chave de partição. Se você estiver familiarizado com bancos de dados relacionais, uma maneira de pensar sobre isso é olhar para uma coleção de itens como sendo um pouco como um JOIN materializado, onde o valor comum do atributo de chave de partição é algo como uma chave estrangeira. Para otimizar seu modelo de dados do DynamoDB, você deve procurar oportunidades para usar coleções de itens na tabela base ou em índices secundários, especialmente itens que se relacionam e que seriam buscados (seletivamente) juntos. Isso pode parecer óbvio, mas vale a pena deixar claro: para estar na mesma coleção de itens, os itens também precisam estar na mesma tabela – a coleção de itens é um subconjunto da tabela.

Por exemplo, você pode representar um carrinho de compras como uma coleção de itens, em que o identificador exclusivo do carrinho (Pete's Cart) é o valor da chave de partição e o identificador de cada produto adicionado ao carrinho é o valor da chave de ordenação (sort). Aparentemente, Pete gosta mais de café do que de vegetais, mas não tanto quanto de chocolates. O número de cada tipo de produto no carrinho é outro atributo (não-chave). A imagem abaixo descreve tal coleção de itens.

Seu código tem uma definição mais rígida, como a captura de tela do NoSQL Workbench abaixo.

As coleções de itens podem existir no índice primário (a tabela base) e/ou em um índice secundário. Vou me aprofundar nos detalhes dos índices secundários em um artigo futuro, então vamos nos concentrar na tabela base. As coleções de itens na tabela base requerem uma chave primária composta (chave de partição e chave de ordenação). Se não houver índices secundários locais (LSIs), a coleção de itens pode abranger várias partições do DynamoDB — ela não começará dessa forma, mas o DynamoDB dividirá automaticamente a coleção de itens entre as partições para acomodar o crescente volume de dados e, às vezes, ele também pode distribuir a coleção de itens entre as partições para fornecer uma taxa de transferência generalizada ou para isolar itens mais quentes (ou intervalos de itens).

É útil pensar em itens e coleções de itens como sendo dois tipos diferentes de registros no DynamoDB. Em uma tabela base com uma chave primária simples (sem chave de ordenação definida), você trabalha inteiramente com itens. Mas se sua tabela tiver uma chave primária composta (chave de partição + chave de ordenação), você trabalhará com coleções de itens. Os itens na coleção são armazenados na ordem dos valores da chave de ordenação e podem ser retornados na ordem descendente ou ascendente.

Uma coleção de itens é mágica – ela nos permite armazenar e recuperar itens relacionados juntos de forma eficiente. Os itens na coleção podem ter esquemas diferentes (o DynamoDB é flexível, lembra?) — cada um representando uma parte do registro geral da coleção de itens.

Se você tiver um item de 200 KB, atualizar até mesmo uma pequena parte desse item consumirá 200 unidades de escrita. Se, ao invés disso, esse item for armazenado como uma coleção de partes de itens em uma coleção, você poderá atualizar qualquer pequena parte para um consumo mínimo de unidade de escrita. Ei, mas isso é só o começo!

Você pode usar a operação Query para recuperar todos os itens da coleção ou apenas aqueles com um intervalo específico de valores de chave de ordenação. A especificação para o intervalo é chamada de condição de chave de ordenação (sort key condition). Dentro da coleção de itens, você pode limitar os itens recuperados para serem aqueles com uma chave de ordenação menor que um valor escolhido, ou maior que, ou mesmo entre dois valores.

Para chaves de ordenação em strings, você também pode usar begin_with (que na verdade é apenas uma variação de between, se você pensar bem). A aplicação de uma condição de chave de ordenação limita efetivamente o intervalo de itens a serem retornados da coleção de itens. É importante ressaltar que apenas os itens da coleção que correspondem à condição da chave de ordenação serão incluídos na medição das unidades de leitura (read units). Isso contrasta com uma expressão de filtro que se aplica após a avaliação das unidades de leitura - portanto, você ainda paga para ler os itens filtrados. Quando você recupera vários itens usando Query (ou Scan), a medição do consumo da unidade de leitura adiciona os tamanhos de todos os itens e depois arredonda para o próximo limite de 4KB (ao invés de arredondar para cada item como GetItem e BatchGetItem fazem). Assim, as coleções de itens permitem que você armazene registros muito grandes, atualize partes seletivas a baixo custo e recupere-as com eficiência ideal.

Coleções de itens (Query) e Scan são, na verdade, os únicos diferenciadores atraentes de custo e desempenho que defendem o armazenamento de dois itens na mesma tabela. Ambos permitem a recuperação de vários itens com os tamanhos de itens agregados arredondados para o próximo limite de 4 KB. Se você não for indexar dois itens juntos na mesma coleção de itens (tabela ou índice secundário) e não quiser retornar ambos de cada Scan, não há vantagem em mantê-los na mesma tabela. Mas certamente existem algumas desvantagens que abordarei um pouco mais tarde. Para todas as outras operações de dados (incluindo vários itens como BatchGetItem, TransactWriteItems, etc), o DynamoDB não se importa se os itens estão na mesma tabela ou não - você verá a mesma medição de armazenamento/taxa de transferência e o mesmo desempenho de qualquer jeito.

‍As vezes, para reunir os dados na mesma coleção de itens, você precisa fazer alguns ajustes nos valores da chave primária. Para ser armazenado na mesma tabela, a mesma definição de chave primária deve ser usada. Exemplos disso incluem armazenar um valor numérico como uma string para corresponder ao tipo de dados da chave de partição ou chave de ordenação ou criar um valor exclusivo para a chave de ordenação onde você não necessariamente tem algo importante para armazenar (usando o mesmo valor que o atributo de chave de partição é comum para isso ao criar um item de "metadados" na coleção).

‍
Imagine uma tabela para armazenar pedidos de clientes para envio. A chave de partição é um identificador de pedido numérico exclusivo (o tipo de dados é número) e você deseja usar uma coleção para armazenar um registro por item de itens do carrinho (identificado por um SKU numérico) e eventos de rastreamento (identificados por um UUID ordenável, como ksuid) para processamento de pedidos. Você deseja recuperá-los juntos para eficiência porque o padrão mais comum é fornecer uma página de rastreamento com os itens comprados mostrados além dos detalhes de rastreamento. Nesse caso, você precisará definir a chave de ordenação com tipo de dados string e converter valores para armazenar esses SKUs numéricos como strings. Há um custo para isso (porque armazenar um número como uma string consome mais bytes), mas vale a pena para obter o benefício da coleção de itens.

Como é fácil acomodar essas alterações ao escrever seus itens na tabela, um desenvolvedor pode fazer isso apenas para todos os itens e coleções de itens, certo? E colocá-los todos na mesma tabela? Faria sentido para todos os clientes do DynamoDB se unirem e armazenarem seus dados em uma tabela multi-tenant gigante? Não, claro que não. Essas técnicas têm um custo e só devem ser usadas quando puderem ser justificadas - para colher os benefícios das coleções de itens.

Finalizando

A parte valiosa e válida da orientação de "design de tabela única" é simplesmente esta:

Use a flexibilidade de esquema e as coleções de itens do DynamoDB para otimizar seu modelo de dados para os padrões de acesso que você precisa cobrir.

Se você estiver migrando de um banco de dados relacional, provavelmente terminará com menos tabelas do que seu antigo modelo totalmente normalizado. Você provavelmente terá mais de uma tabela e deve usar qualquer número de Índices Secundários Globais (GSIs) necessários para atender aos seus padrões secundários.

Sim, é isso. Realmente nunca houve necessidade de criar uma nova terminologia. O "design de tabela única" confundiu algumas pessoas e levou muitas outras a um caminho doloroso, complexo e caro (detalhes sobre isso em um próximo artigo) quando foi interpretado literalmente e, em seguida, deturpado como "melhor prática".

É hora de deixar essa terminologia de lado - ficar com a flexibilidade do esquema e as coleções de itens.

Fique de olho em artigos futuros em que discutirei as nuâncias de LSIs e GSIs e explicarei por que a "sobrecarga de GSI" é um padrão de modelagem de araque.

Apêndice: O que eu saberia sobre o DynamoDB afinal?

Até recentemente, eu trabalhava na AWS. Comecei como gerente técnico de contas em 2016 na equipe de contas que oferece suporte à Amazon.com como cliente corporativo da AWS. Minha área de foco era ajudar a Amazon a atingir algumas metas organizacionais ambiciosas: 1) migrar projetos críticos de bancos de dados transacionais de bancos de dados relacionais tradicionais para bancos de dados distribuídos desenvolvidos especificamente para computação em nuvem (como DynamoDB); 2) cargas transacionais de segundo nível "lift and shift" do Oracle para o Aurora; e 3) mover todo o armazenamento de dados do Oracle para o Redshift. Foi uma experiência fantástica em geral, mas a parte que mais gostei foi testemunhar a redução drástica na carga operacional e as melhorias na disponibilidade e latência que o DynamoDB proporcionou. Trabalhei com centenas de equipes de desenvolvedores da Amazon.com para revisar seus modelos de dados, ensiná-los sobre como gerenciar limites, dimensionamento, alarmes e painéis do DynamoDB. Sentei-me nas salas de guerra para eventos de pico, como o Prime Day, como ponto de contato para qualquer tipo de preocupação relacionada ao DynamoDB que surgisse com o rápido crescimento do tráfego de eventos. Não foi fácil para todos fazer a mudança de paradigma do modelo de dados, mas quando esse programa foi concluído, todos os desenvolvedores rapidamente passaram a considerar todas as vantagens garantidas do DynamoDB. Eles passaram a dedicar muito mais tempo às coisas que faziam a diferença para seus clientes — ver isso me impressionou profundamente.

Em 2018, tornei-me um arquiteto de soluções especializado em DynamoDB — parte de uma pequena equipe que trabalha com os maiores clientes corporativos (externos) da AWS. Eu os ajudei a desenvolver modelos de dados DynamoDB eficazes e eficientes para uma ampla variedade de casos de uso e padrões de acesso, e ensinei muitos desenvolvedores a operar bem com o DynamoDB. Meus últimos 18 meses na AWS foram gastos como gerente de produto para o serviço DynamoDB. Também dei centenas de consultorias a engenheiros de várias equipes de serviço da AWS como parte de um programa de "office hours" para o DynamoDB — revisando modelos de dados, fornecendo orientação de arquitetura mais ampla e ensinando sobre como o DynamoDB funciona e os insights revelados pelas métricas.

Tudo isso é para dizer que já vi muitos casos de uso de produção para o DynamoDB (de centenas de solicitações por dia a milhões de solicitações por segundo) e tenho uma forte noção da maneira como os desenvolvedores (na Amazon.com, dentro da AWS e em muitas outras empresas ao redor do mundo) estão realmente usando o DynamoDB na prática.

Construindo Arquiteruras Orientadas a Eventos

Eduardo Rabelo — Tue, 14 Mar 2023 00:11:57 +0000

🇧🇷 Tradução completa do Building Event Driven
Architectures do Serverless Land.

Nota: Essa é uma tradução livre, não oficial, realizada no meu tempo livre - Eduardo Rabelo.

Construindo Arquiteruras Orientadas a Eventos

As arquiteturas orientadas a eventos são um estilo de arquitetura que pode ajudá-lo a aumentar a agilidade de criar aplicativos confiáveis e escaláveis. Serviços serverless como EventBridge, Step Functions, SQS, SNS e Lambda têm uma afinidade natural com arquiteturas orientadas a eventos - elas são invocadas por eventos, emitem eventos e possuem recursos nativos para construir com eventos.

Saiba mais sobre arquiteturas orientadas a eventos, incluindo conceitos-chave, práticas recomendadas, serviços da AWS e recursos de introdução.

Este guia irá te apresentar a arquiteturas orientadas a eventos. Você vai compreender os padrões das arquiteturas orientadas a eventos e os serviços da AWS usados para implementá-los. Aprenda as práticas recomendadas para criar arquiteturas orientadas a eventos, desde a criação de esquemas de eventos até o tratamento de conceitos como a idempotência. Ao concluir esse guia, você encontrará recursos extras para expandir seu conhecimento em como criar arquiteturas orientadas a eventos na AWS.

A tradução completa no GitHub

oieduardorabelo / construindo-arquiteruras-orientadas-a-eventos-serverless-land

🇧🇷 Tradução completa do Building Event Driven Architectures do Serverless Land.

Nota: Essa é uma tradução livre, não oficial, realizada no meu tempo livre - Eduardo Rabelo.

Construindo Arquiteruras Orientadas a Eventos

Saiba mais sobre arquiteturas orientadas a eventos, incluindo conceitos-chave, práticas recomendadas, serviços da AWS e recursos de introdução.

View on GitHub

10 melhores práticas para nomes de arquivos e buckets no Amazon S3

Eduardo Rabelo — Mon, 13 Mar 2023 03:44:07 +0000

O Amazon S3 é um serviço de armazenamento simples que oferece escalabilidade, disponibilidade de dados, segurança e desempenho que são líderes do setor. Ao nomear seus buckets do S3, siga estas práticas recomendadas para garantir um gerenciamento de dados tranquilo e eficiente.

Amazon S3 é um popular serviço de armazenamento em nuvem fornecido pela Amazon Web Services (AWS). O S3 é um armazenamento de valor-chave simples com o benefício adicional de oferecer baixa latência e alta durabilidade.

Ao trabalhar com o S3, é importante seguir as práticas recomendadas para nomear objetos armazenados nos buckets. Isso ajudará você a manter seus dados organizados e facilitará a localização do que você está procurando.

Neste artigo, discutiremos as 10 melhores práticas para nomes de arquivos e buckets no Amazon S3.

1. Use uma convenção de nomenclatura consistente

Quando você tem uma convenção de nomenclatura consistente, é muito mais fácil encontrar os arquivos que está procurando. Por exemplo, se todos os seus arquivos de imagem forem nomeados com a data primeiro, seguida por uma descrição da imagem, será muito mais fácil encontrar uma imagem específica do que se todos fossem nomeados aleatoriamente.

Também é importante usar uma convenção de nomenclatura consistente porque facilita a automatização de tarefas. Por exemplo, se você sabe que todos os seus arquivos de imagem são nomeados da mesma maneira, você pode facilmente escrever um script que faça backup deles automaticamente em outro local.

Por fim, usar uma convenção de nomenclatura consistente facilita o compartilhamento de arquivos com outras pessoas. Se você sabe que todos os seus arquivos são nomeados da mesma maneira, basta dizer a alguém para ir ao seu site e procurar o nome do arquivo que está procurando. Isso é muito mais fácil do que tentar explicar onde encontrar um arquivo quando os nomes estão por toda parte.

2. Evite caracteres especiais em nomes de buckets

Quando você cria um bucket, a Amazon atribui automaticamente a ele um endpoint de site. Este é o URL que você usa para acessar o conteúdo do seu bucket quando está usando o recurso de hospedagem de site estático do S3.

No entanto, se o nome do seu bucket contiver caracteres especiais, como pontos ou hífens, o endpoint do site não funcionará. Isso significa que qualquer pessoa que tentar visitar seu site receberá uma mensagem de erro.

Para evitar esse problema, certifique-se de que seus nomes de bucket não contenham nenhum caractere especial.

3. Não use pontos nos nomes dos buckets

Quando você cria um bucket com um ponto no nome, como "meu.projeto", o S3 irá tratá-lo como dois buckets diferentes: "meu" e "projeto". Isso pode causar problemas porque, ao tentar acessar o bucket "meu.projeto", você pode ser redirecionado para o bucket "projeto".

Para evitar esse problema, simplesmente não use pontos em seus nomes de bucket.

4. Os nomes dos buckets são globalmente únicos

Quando você cria um novo bucket, o Amazon S3 verifica se o nome escolhido está disponível como um subdomínio DNS (Domain Name System). Se o nome estiver disponível, o Amazon S3 atribuirá esse nome ao seu bucket. No entanto, se o nome escolhido não estiver disponível, o Amazon S3 retornará uma mensagem de erro.

Isso é importante porque significa que você poderia criar inadvertidamente dois buckets com o mesmo nome e esses buckets seriam acessíveis a partir de URLs diferentes. Por exemplo, digamos que você crie um bucket chamado "example-bucket" na região Leste dos EUA (N. Virgínia, us-east-1). Em seguida, outra pessoa cria um bucket com o mesmo nome na região da UE (Irlanda, eu-west-1). Embora sejam dois buckets diferentes, ambos podem ser acessados usando a URL "example-bucket.s3.amazonaws.com".

Para evitar esse problema, escolha um nome único para seu bucket e use o identificador de região ao criar buckets em diferentes regiões. Por exemplo, você pode nomear seu bucket "example-bucket-us-east-1" na região US East (N. Virginia) e "example-bucket-eu-west-1" na região EU (Irlanda).

5. Mantenha seus buckets organizados

Quando você tem muitos dados no S3, pode ser difícil acompanhar tudo sem uma estrutura organizacional clara. Ao usar uma convenção de nomenclatura consistente para seus buckets, você pode garantir que todos os seus dados sejam fáceis de localizar e gerenciar.

Uma boa maneira de organizar seus buckets é usar um prefixo ou sufixo que indique o tipo de dados armazenados em cada bucket. Por exemplo, você pode usar o prefixo "dados-brutos" (raw-data) para buckets contendo arquivos não tratados, "dados-processados" para buckets contendo arquivos de dados processados e assim por diante.

Ao usar uma convenção de nomenclatura consistente, você pode tornar mais fácil para você e para outras pessoas encontrar e usar os dados armazenados em seus buckets do S3.

6. Crie e aplique políticas para o gerenciamento do ciclo de vida de objetos no S3

Os objetos no S3, por padrão, são colocados em uma classe de armazenamento Standard, o que significa que eles são armazenados indefinidamente, a menos que você especifique uma classe de armazenamento diferente ou exclua o objeto. No entanto, você pode não querer manter todos os objetos do S3 para sempre. Por exemplo, você pode precisar acessar determinados objetos apenas por um tempo limitado, após o qual poderá excluí-los.

A criação e aplicação de políticas para o gerenciamento do ciclo de vida de objetos no S3 permite que você exclua objetos automaticamente após um determinado período de tempo, o que pode ajudar a economizar nos custos de armazenamento. Ele também pode ajudar a melhorar a segurança, garantindo que objetos antigos e não utilizados não sejam deixados espalhados onde possam ser acessados por usuários não autorizados.

Para criar e aplicar políticas para o gerenciamento do ciclo de vida do objeto S3, você pode usar o AWS Management Console, os SDKs da AWS ou a AWS Command Line Interface (AWS CLI).

7. Habilite o versionamento em todos os buckets

O controle de versão é um recurso crítico do S3 que permite manter várias versões de um objeto no mesmo bucket. Isso é útil por vários motivos, como poder reverter para versões anteriores de um objeto ou recuperar-se de exclusões acidentais.

Habilitar o controle de versão em um bucket é fácil e leva apenas alguns cliques no console AWS. Depois de ativados, todos os objetos armazenados no bucket terão seu próprio ID de versão única. Esses IDs podem ser usados para recuperar versões específicas de um objeto quando necessário.

8. Criptografar dados em repouso (Encrypt data at rest)

Quando os dados são armazenados no S3, eles são armazenados fisicamente em servidores pertencentes e operados pela Amazon. Embora a Amazon faça um ótimo trabalho protegendo seus servidores, eles não podem garantir que os servidores nunca sejam comprometidos.

Se os dados forem criptografados em repouso, mesmo que os servidores sejam comprometidos, os dados ainda estarão seguros porque serão ilegíveis sem as chaves de criptografia.

Há duas maneiras principais de criptografar dados em repouso no S3: criptografia do lado do servidor e criptografia do lado do cliente.

A criptografia do lado do servidor é quando a Amazon criptografa os dados antes de serem gravados no servidor. Os dados são descriptografados automaticamente quando são lidos do servidor.

A criptografia do lado do cliente é quando os dados são criptografados pelo cliente antes de serem enviados para a Amazon. Os dados permanecem criptografados enquanto são armazenados no servidor e só são descriptografados quando o cliente os recupera.

Ambos os métodos são igualmente seguros, mas a criptografia do lado do cliente requer mais trabalho para configurar.

9. Monitore e audite o acesso aos seus buckets

Se você não estiver monitorando e auditando o acesso aos seus buckets, não terá como saber quem está acessando seus dados ou o que eles estão fazendo com eles. Isso pode levar a violações de dados, vazamentos de dados ou até mesmo perda de dados.

Para evitar esses riscos, você deve sempre monitorar e auditar o acesso aos seus buckets do S3. A AWS fornece um serviço chamado CloudTrail que facilita isso. Com o CloudTrail, você pode ver quem acessou seus buckets, o que eles fizeram e quando o fizeram.

Você também pode usar o CloudTrail para configurar alertas para ser notificado imediatamente se alguém tentar acessar seus buckets sem permissão. Dessa forma, você pode agir rapidamente para evitar qualquer dano.

10. Limite o acesso público aos seus buckets

Quando você cria um novo bucket do S3, ele é automaticamente privado. No entanto, existem várias maneiras de alguém tornar seu bucket público sem que você perceba. Por exemplo, se você usar um console do Amazon S3 para fazer upload de arquivos para um bucket e esquecer de definir as permissões, qualquer pessoa poderá acessar esses arquivos.

Para evitar isso, é importante limitar o acesso público aos seus buckets. Você pode fazer isso configurando uma política de bucket que nega todo o acesso público ou usando Amazon S3 Block Public Access.

Ambos os métodos ajudarão a garantir que apenas usuários autorizados possam acessar seus buckets S3 e que seus dados estejam seguros.

Créditos

Escrito originalmente por Janet Maples, em 10 S3 Naming Convention Best Practices.