Forem: Yeison Cruz

Why you should never migrate everything at once

Yeison Cruz — Mon, 16 Mar 2026 13:20:25 +0000

You've assessed your environment. You know why you're modernizing. You understand the trade-offs. Now comes the question everyone dreads:

How do we actually move this thing?

And someone in the room always suggests: "Let's just migrate everything over a weekend."

No. Just... no.

Why "big bang" migrations fail

Big bang means you flip a switch, move everything at once, and hope it works. It's tempting because it sounds simple.

It's not simple. It's a disaster waiting to happen.

Here's what goes wrong:

You can't test everything. You think you can, but you can't. There's always something you missed.

You can't roll back easily. Once you've moved 50 services, rolling back means moving 50 services back. Good luck doing that at 2 AM.

You can't learn from mistakes. If something breaks, you're fixing it under pressure with everyone watching.

You put all your eggs in one basket. One mistake and the entire business is down.

The only time big bang works: When you're migrating something so simple it doesn't matter. A static website. A single service with no dependencies. That's it.

For everything else? Phase it.

What phased migration actually means

You break the migration into small, manageable chunks. You move one piece at a time. You validate it works. Then you move the next piece.

The benefits:

You learn as you go. The first migration teaches you what works and what doesn't.

You can roll back easily. If something breaks, you only roll back one piece, not everything.

You reduce risk. A small failure is manageable. A total failure is career-ending.

You show progress. Leadership sees results every few weeks, not "we'll be done in 6 months, trust us."

How to design your phases

Step 1: Map your dependencies

You can't migrate things in random order. You need to know what depends on what.

Draw it out:

What talks to what?
What can run independently?
What's blocking other things?

Example:

Users → Load Balancer → App Servers → Database → S3
Background Jobs → Queue → Workers → Database

You can't migrate the database before the app servers. You can't migrate the app servers before you have a load balancer.

Step 2: Identify your migration candidates

Not everything is equally easy to migrate. Some things are simple. Some are nightmares.

Easy candidates (start here):

Stateless services (no database, no persistent storage)
Low-traffic services (if it breaks, not many people notice)
Non-critical services (internal tools, admin panels)
Services with good test coverage

Hard candidates (save for later):

Stateful services (databases, file storage)
High-traffic services (your main API, payment processing)
Critical services (if it's down, the business is down)
Services with no tests (you don't know if it works until it doesn't)

Step 3: Group into waves

A wave is a batch of services you migrate together. Usually 2-4 weeks per wave.

Wave 1: The pilot

Pick 1-2 low-risk services
Migrate them fully
Validate everything works
Document what you learned

Goal: Prove the process works. Build confidence. Find the problems when the stakes are low.

Wave 2-3: Low-hanging fruit

Migrate the easy stuff
Build momentum
Refine your process
Train the team

Goal: Show progress. Get quick wins. Make leadership happy.

Wave 4-6: The meat of it

Migrate the core services
This is where the real work happens
Move carefully, test thoroughly

Goal: Get the important stuff done without breaking anything.

Wave 7+: The hard stuff

Databases, stateful services, critical systems
By now you know what you're doing
You've learned from earlier mistakes

Goal: Finish strong. Migrate the scary stuff with confidence.

Step 4: Plan your rollback strategy

Before you migrate anything, know how to undo it.

For each wave, document:

How to roll back (step by step)
How long rollback takes
What data might be lost
Who makes the call to roll back

Example rollback plan:

Switch DNS back to old load balancer (5 minutes)
Verify old system is receiving traffic (2 minutes)
Stop new services to avoid confusion (1 minute)
Sync any data created during migration (30 minutes)

If you can't roll back in under an hour, your phase is too big.

Migration strategies by service type

Stateless services (APIs, web apps)

Strategy: Blue/green deployment

Deploy new version alongside old version
Route 10% of traffic to new version
Monitor for errors
Gradually increase to 50%, then 100%
Shut down old version

Why it works: You can roll back instantly by routing traffic back.

Databases

Strategy: Parallel run

Set up new database
Replicate data from old to new (continuously)
Run both databases in parallel
Switch reads to new database (writes still go to old)
Monitor for issues
Switch writes to new database
Keep old database running for a week
Shut down old database

Why it works: You're never fully committed until you're sure it works.

Background jobs

Strategy: Gradual migration

Deploy new workers alongside old workers
Route new jobs to new workers
Let old workers finish existing jobs
Shut down old workers when queue is empty

Why it works: No jobs are lost, no downtime.

File storage

Strategy: Lazy migration

Set up new storage (S3, EFS, whatever)
Write new files to new storage
Keep old files in old storage
Migrate old files in batches (off-peak hours)
Update app to check both locations
Eventually everything's in new storage

Why it works: No big bang, no downtime, no rush.

Real-world example: E-commerce site migration

The setup:

Monolithic app on EC2
MySQL database
Redis cache
S3 for images
10,000 daily users

Wave 1: Static assets (Week 1-2)

Migrate images to CloudFront + S3
Update app to use new URLs
Validate images load correctly
Risk: Low. Rollback: Easy.

Wave 2: Redis cache (Week 3-4)

Set up ElastiCache
Run both caches in parallel
Switch to ElastiCache
Monitor for issues
Risk: Low. Rollback: Easy.

Wave 3: App servers (Week 5-8)

Containerize app (ECS)
Deploy behind new ALB
Route 10% traffic to new app
Gradually increase to 100%
Risk: Medium. Rollback: Moderate.

Wave 4: Database (Week 9-12)

Set up RDS with replication from old DB
Switch reads to RDS
Monitor performance
Switch writes to RDS
Keep old DB running for 2 weeks
Risk: High. Rollback: Hard but possible.

Wave 5: Cleanup (Week 13-14)

Shut down old infrastructure
Update documentation
Celebrate

Total time: 14 weeks. Zero downtime. No disasters.

Common mistakes

Making phases too big. If a phase takes more than 4 weeks, it's too big. Break it down.

Not testing rollback. You don't want to figure out how to roll back at 3 AM when production is down.

Skipping the pilot. The first migration teaches you everything. Don't skip it.

Moving too fast. Velocity is good, but not at the expense of risk. Give each phase time to stabilize.

Not documenting lessons learned. What you learn in Wave 1 should improve Wave 2. Write it down.

Ignoring dependencies. You can't migrate the app before the database. Map it out first.

What you should have for each phase

Before the phase:

List of what's being migrated
Dependencies mapped out
Rollback plan documented
Success criteria defined
Team knows their roles

During the phase:

Monitoring and alerts set up
Communication plan (who to notify, when)
Go/no-go decision points
Rollback trigger conditions

After the phase:

Validation that everything works
Performance comparison (old vs. new)
Lessons learned documented
Cleanup tasks completed

The golden rule

If you can't roll back in under an hour, your phase is too big.

Break it down. Make it smaller. Reduce the risk.

You can't optimize everything (And that's okay)

Yeison Cruz — Mon, 09 Mar 2026 16:11:59 +0000

You know why you're modernizing. You've assessed your environment. Now comes the fun part: actually doing it.

And here's the problem: you can't optimize for everything at once.

You want it cheap. You want it safe. You want it fast. You want it compliant. Pick two. Maybe three if you're lucky.

Let's talk about how to balance these four things without losing your mind.

The four forces trying to kill each other

Cost: Keep the CFO happy

You need to save money. Or at least not spend more. Leadership approved this modernization because you promised it would be cheaper (or you lied and said it would be).

What cost wants:

Use the cheapest services possible
Turn things off when not in use
Don't over-provision
Avoid expensive managed services

Risk: Don't break production

You need to not blow up the business. One bad deploy and you're on the front page of Hacker News for all the wrong reasons.

What risk wants:

Test everything twice
Run things in parallel
Have rollback plans
Move slowly and carefully

Velocity: Ship faster

You need to deliver value quickly. Your competitors aren't waiting. Your customers want features now. Leadership wants to see progress.

What velocity wants:

Move fast
Automate everything
Skip the unnecessary stuff
Ship and iterate

Compliance: Keep the lawyers happy

You need to meet regulations. HIPAA, SOC 2, GDPR, PCI-DSS, whatever applies to you. Fail an audit and you lose customers. Or get fined. Or both.

What compliance wants:

Document everything
Audit trails everywhere
Encrypt all the things
Lock everything down

Why they fight

Cost vs. Risk: The cheapest option is usually the riskiest. Running everything in one availability zone saves money until it doesn't.

Velocity vs. Risk: Moving fast means taking shortcuts. Taking shortcuts means things break.

Velocity vs. Compliance: Documentation and approvals slow you down. But skip them and you fail your audit.

Cost vs. Compliance: Compliance is expensive. Encryption, logging, monitoring, auditing—it all costs money.

See the problem? Every decision is a trade-off.

How to actually balance them

1. Know which one matters most (right now)

You can't optimize for all four equally. So don't try.

If you're in healthcare or finance: Compliance and risk come first. Period. You can't afford to fail an audit or have a breach.

If you're a startup burning cash: Cost and velocity matter most. You need to move fast and not run out of money.

If you're a mature company with customers: Risk is #1. Downtime costs you more than anything else.

If you're being acquired: Velocity matters. You have a deadline and it's non-negotiable.

Pick your priority. Everything else is secondary.

2. Set boundaries, not goals

Don't try to minimize cost. Set a budget and stay under it.

Don't try to eliminate risk. Decide what's acceptable and work within it.

Don't try to maximize velocity. Set a timeline and hit it.

Don't try to be "fully compliant." Meet the requirements and stop there.

Example:

Budget: Don't spend more than $50K/month
Risk: No more than 4 hours of downtime per year
Velocity: Ship the first wave in 8 weeks
Compliance: Pass SOC 2 audit by Q3

Now you have constraints. Work within them.

3. Make trade-offs explicit

Every decision has a cost. Make it visible.

Scenario: You need to migrate a database.

Option A: Lift-and-shift to EC2

Cost: Low (you control the instance size)
Risk: High (you manage backups, patches, failover)
Velocity: Fast (just move it)
Compliance: Medium (you handle encryption and logging)

Option B: Migrate to RDS

Cost: Medium (managed service costs more)
Risk: Low (AWS handles backups and failover)
Velocity: Medium (some reconfiguration needed)
Compliance: High (built-in encryption and audit logs)

Option C: Refactor to Aurora Serverless

Cost: Variable (scales with usage)
Risk: Medium (new technology, learning curve)
Velocity: Slow (requires code changes)
Compliance: High (same as RDS)

There's no "right" answer. It depends on your priorities.

If cost is #1, pick A. If risk is #1, pick B. If you need compliance and can wait, pick C.

4. Use the 80/20 rule

You don't need perfect. You need good enough.

For cost: Cut the obvious waste first. Unattached volumes, idle load balancers, oversized instances. That's 80% of your savings with 20% of the effort.

For risk: Focus on the critical systems. Your payment API needs five-nines uptime. Your internal admin tool? It can go down for an hour.

For velocity: Automate the repetitive stuff. CI/CD, infrastructure provisioning, testing. Don't automate the one-off tasks.

For compliance: Meet the requirements that matter. Encrypt data at rest and in transit. Enable CloudTrail. Set up proper IAM. That covers 80% of most audits.

5. Phase your approach

You don't have to balance everything on day one.

Phase 1: Get it working

Priority: Velocity and risk
Goal: Migrate without breaking anything
Trade-off: Higher costs, basic compliance

Phase 2: Optimize costs

Priority: Cost
Goal: Right-size resources, implement auto-scaling
Trade-off: Some risk (you're changing things)

Phase 3: Harden security and compliance

Priority: Compliance and risk
Goal: Pass audits, improve reliability
Trade-off: Slower velocity, some cost increase

Phase 4: Improve velocity

Priority: Velocity
Goal: Better CI/CD, faster deployments
Trade-off: Upfront cost for long-term gains

Each phase focuses on 1-2 priorities. You're not juggling all four at once.

Real-world examples

Example 1: The startup

Situation: 6 months of runway, need to ship fast, can't afford downtime.

Priorities: Velocity > Risk > Cost > Compliance

Decisions:

Use managed services (RDS, ECS, ALB) to move fast
Multi-AZ for critical services only
Basic monitoring and logging
Compliance is "good enough" for now

Trade-off: Higher costs, but they're shipping weekly and staying up.

Example 2: The healthcare company

Situation: HIPAA required, can't afford a breach, budget is tight.

Priorities: Compliance > Risk > Cost > Velocity

Decisions:

Everything encrypted (at rest and in transit)
Full audit logging with CloudTrail and CloudWatch
Private subnets, no public access
Slower deployments with extensive testing

Trade-off: Takes longer to ship, but they pass audits and sleep at night.

Example 3: The enterprise

Situation: Millions of users, downtime costs $100K/hour, compliance required.

Priorities: Risk > Compliance > Velocity > Cost

Decisions:

Multi-region active-active setup
Automated failover and rollback
Extensive monitoring and alerting
Full compliance controls

Trade-off: Expensive, but they can't afford to be down.

Common mistakes

Trying to optimize everything at once. You'll fail. Pick your battles.

Not communicating trade-offs. When you choose velocity over cost, tell people. When you choose risk over velocity, explain why.

Ignoring the business context. A startup and an enterprise have different priorities. Act accordingly.

Setting unrealistic expectations. You can't have the cheapest, fastest, safest, most compliant solution. Stop promising you can.

Not revisiting priorities. What matters today might not matter in 6 months. Reassess regularly.

What you should remember

You're juggling four things: cost, risk, velocity, and compliance.

You can't optimize for all of them. Pick 1-2 priorities and work within constraints for the rest.

Make trade-offs explicit. Document them. Communicate them.

Phase your approach. Focus on different priorities at different times.

And most importantly: good enough is good enough. Perfect is the enemy of done.

Cloud modernization without a reason is just expensive busywork

Yeison Cruz — Mon, 02 Mar 2026 18:38:42 +0000

You've assessed your AWS environment. You know what's running, what it costs, and what's held together with duct tape and prayers.

Now comes the question nobody wants to ask: Why are we modernizing this?

"Because it's legacy" isn't an answer. "Because the cloud is the future" isn't either. You need real reasons. Business reasons. Technical reasons. The kind that justify the time, money, and risk.

Let's figure out what they are.

Why this matters

Because modernization without a clear driver is just expensive busywork.

I've seen teams spend 6 months migrating to containers because "that's what everyone's doing," only to realize they solved zero actual problems. The app runs the same. Costs went up. And now they have Kubernetes to maintain.

Don't be that team.

Technical drivers: What's actually broken?

These are the problems keeping your engineers up at night (or paging them at 3 AM).

1. Scalability issues

The symptom: Your app can't handle growth.

Black Friday comes around and your servers fall over. You got mentioned on Twitter and the site went down. You're adding customers faster than you can provision hardware.

The question: Can your current setup scale? Or are you hitting limits?

If you're manually adding EC2 instances every time traffic spikes, that's a driver. If your database is maxed out and you can't upgrade it anymore, that's a driver.

2. Reliability problems

The symptom: Things break. A lot.

Your uptime is 95% when it should be 99.9%. You have outages every month. One server dies and the whole app goes down. Your disaster recovery plan is "hope nothing bad happens."

The question: Can you afford the downtime?

If your SLA says 99.9% but you're delivering 95%, that's a driver. If you're losing customers because the site's always down, that's a driver.

3. Security vulnerabilities

The symptom: You're one breach away from a very bad day.

Your servers are running Ubuntu 14.04 (end-of-life was 2019). Nobody's patched anything in 2 years. Your database is exposed to the internet. You found AWS keys in a public GitHub repo.

The question: What's your risk tolerance?

If you're in healthcare, finance, or anything regulated, this is probably your #1 driver. If you're storing customer data and your security is Swiss cheese, fix it before someone else finds out.

4. Deployment speed

The symptom: Shipping features takes forever.

It takes 3 weeks to deploy a one-line change. Releases happen once a quarter. Deployments require a 6-hour maintenance window and a prayer. Rolling back a bad deploy means restoring from backup.

The question: How fast do your competitors move?

If they're shipping daily and you're shipping quarterly, that's a driver. If your developers spend more time deploying than coding, that's a driver.

5. Operational overhead

The symptom: Your team is drowning in maintenance.

You're spending 80% of your time patching servers, managing backups, and fighting fires. You can't work on new features because you're too busy keeping the lights on. Your on-call rotation is brutal.

The question: What could your team build if they weren't babysitting infrastructure?

If you're managing your own Kubernetes cluster when you could use EKS, that's a driver. If you're running your own MySQL when RDS exists, that's a driver.

6. Technology obsolescence

The symptom: Your stack is ancient and nobody wants to touch it.

You're running PHP 5.6. Your database is MySQL 5.5. You can't hire developers because nobody wants to work with 10-year-old tech. The vendor stopped supporting it 3 years ago.

The question: Can you even maintain this?

If you can't find people to work on it, that's a driver. If the vendor dropped support and you're on your own, that's a driver.

Business drivers: What does leadership care about?

These are the reasons that get budget approved.

1. Cost reduction

The reality: You're spending too much.

You're paying for a data center lease. You're over-provisioned for peak traffic 24/7. You're paying for licenses you don't need. Your AWS bill is out of control because nobody's optimizing it.

The pitch: "We can cut infrastructure costs by 30% in 12 months."

This is the easiest driver to sell. CFOs love saving money. Just make sure you can actually deliver on it.

2. Time-to-market

The reality: You're too slow.

Your competitors are shipping features weekly. You're shipping quarterly. By the time you launch something, the market's moved on. You're losing deals because you can't deliver fast enough.

The pitch: "We can go from quarterly releases to weekly releases."

This resonates with product teams and executives. Faster shipping = more revenue = happy stakeholders.

3. Geographic expansion

The reality: You need to be in more places.

You're US-only but need to expand to Europe. Your latency in Asia is terrible. You need to comply with data residency laws. Your single data center can't serve a global customer base.

The pitch: "We can deploy to 5 regions and cut latency by 70%."

If your business is going global, your infrastructure needs to follow. That's a clear driver.

4. Customer experience

The reality: Your users are complaining.

Your app is slow. Pages take 10 seconds to load. Mobile experience is terrible. Users are leaving because the competition is faster.

The pitch: "We can cut page load times from 10 seconds to 2 seconds."

Better experience = happier customers = more retention = more revenue. Easy sell.

5. Compliance requirements

The reality: You need to meet regulations or you can't do business.

You need SOC 2 to close enterprise deals. You need HIPAA compliance to work with healthcare. You need GDPR compliance to operate in Europe. Your current setup can't pass an audit.

The pitch: "We need this to close $5M in deals."

When compliance blocks revenue, you get budget. Fast.

6. M&A integration

The reality: You acquired a company and need to integrate their systems.

You bought a competitor and now you have two completely different stacks. You need to consolidate. You need to migrate their customers to your platform. You need to do it without breaking anything.

The pitch: "We need to integrate the acquisition within 6 months."

M&A timelines are non-negotiable. If this is your driver, you'll get resources.

How to identify your drivers

Talk to people. Not just engineers. Talk to:

Product managers (what features are blocked by infrastructure?)
Sales (what deals are we losing and why?)
Support (what are customers complaining about?)
Finance (where are we bleeding money?)
Leadership (what keeps them up at night?)

Look at the data:

Incident reports (what breaks most often?)
Cost reports (where's the money going?)
Performance metrics (what's slow?)
Customer feedback (what are they saying?)

Prioritize ruthlessly:

What's costing us the most money?
What's the biggest risk?
What's blocking the most revenue?
What's causing the most pain?

What you should have when you're done

A simple list with:

Technical drivers (ranked by impact)
Business drivers (ranked by value)
The one or two that matter most

That's it. You don't need 10 drivers. You need the 1-2 that justify the investment.

Common mistakes

Don't make up drivers. "We should use Kubernetes because it's cool" isn't a driver. "We need Kubernetes because we can't scale our current setup" is.

Don't ignore the business side. Technical excellence doesn't matter if it doesn't solve a business problem.

Don't try to solve everything. You can't fix scalability, security, cost, and speed all at once. Pick your battles.

Don't skip this step. If you can't articulate why you're modernizing, you shouldn't be modernizing.

What's next?

Now you know why you're doing this. Next comes the hard part: figuring out how to do it without breaking everything.

But at least now when your boss asks "why are we spending $500K on this?" you'll have an answer.

And it'll be a good one.

Assessing an AWS Legacy Environment

Yeison Cruz — Mon, 23 Feb 2026 14:15:15 +0000

You just got handed the keys to an AWS account that's been running for... who knows how long. The person who built it? Left the company 18 months ago. The documentation? "It's all in Confluence" (it's not).

Now leadership wants to know: "Can we modernize this?" And you're thinking: "I don't even know what this is yet."

Let's fix that.

Why bother with an assessment?

Because you can't fix what you don't understand. And you definitely can't tell your boss "this will take 6 months and cost $200K" when you haven't even looked under the hood.

An assessment answers three simple questions:

What are we running?
How much is it costing us?
What's about to explode?

That's it. No 50-page reports. No fancy architecture diagrams that nobody reads. Just the facts.

Start with the obvious: What's actually running?

Open the AWS Console. Click around. Seriously.

Go to EC2. How many instances do you have? Are they all running? Do they have names, or are they just "i-0a1b2c3d4e5f" with no tags?

Check RDS. Any databases? What versions? (Spoiler: probably outdated)

Look at Lambda. How many functions? Anyone know what they do?

Pro tip: If nothing has tags, you're in for a rough time. Tags are how you know "this server runs the payment API" vs "this is Steve's test box from 2022 that nobody dared to delete."

Follow the money (Because your CFO will)

Go to Cost Explorer. Look at last month's bill.

What's eating the budget?

Is it EC2 instances running 24/7 when they could shut down at night?
Data transfer costs because someone's downloading terabytes to their laptop?
A NAT Gateway that costs more than the application it supports?

Look for the stupid stuff:

Storage volumes attached to nothing (you're paying for ghost hard drives)
Load balancers with zero traffic (still $16/month each)
Elastic IPs sitting idle ($3.60/month adds up when you have 47 of them)

This is low-hanging fruit. You can save money today just by cleaning up the mess.

Security Check (Before someone hacks you)

You don't need to be a security expert. Just answer these questions:

Can anyone on the internet SSH into your servers? (Check security groups for 0.0.0.0/0 on port 22)

Are your S3 buckets public? (They shouldn't be, but you'd be surprised)

Is anyone using the root account? (They better not be)

When was the last time someone rotated access keys? (If the answer is "never," we have a problem)

AWS has tools for this (Trusted Advisor, Security Hub), but honestly? Just click through the console and look for red flags. You'll find them.

Map the dependencies (AKA "What breaks if I touch this?")

This is the hard part. You need to figure out what talks to what.

Start simple:

Users hit a load balancer
Load balancer talks to app servers
App servers talk to a database
Maybe there's an S3 bucket somewhere
Probably some Lambda functions doing... something

How do you figure this out?

Look at the code (if you can find it)
Check CloudWatch logs for traffic patterns
Ask the team (the junior dev who's been here 8 months knows more than you think)

Draw it on a whiteboard. Boxes and arrows. Nothing fancy. Just "if I turn off X, does Y break?"

Spot the Technical Debt

Things that should make you nervous:

EC2 instances that have been running since 2019 and nobody knows what they do
Databases running MySQL 5.6 (end-of-life was years ago)
Manual deployments (someone SSHs in and runs commands)
No backups (or backups that nobody's ever tested)
Everything in one availability zone (one AWS hiccup = you're down)

Things that are costing you money:

Servers sized for peak traffic running 24/7
Self-managed databases when RDS would be cheaper and easier
No auto-scaling (you're paying for capacity you don't need)

Make a list. Prioritize by "what's going to bite us first."

Know your baseline (Or you can't prove you made it better)

Before you change anything, write down how things perform now.

Capture the basics:

How fast do pages load?
What's the error rate?
How much CPU/memory are we using?
How long do database queries take?

You need this. Because in 6 months when you've modernized everything, someone will ask "did this actually help?" and you'll want receipts.

What you should have when you're done

A simple document (Google Doc, Notion, whatever) with:

List of what's running (and what it costs)
Security issues (ranked by "how screwed are we?")
Dependency map (even if it's just boxes and arrows)
Technical debt list (prioritized)
Performance numbers (your baseline)

That's it. No 100-slide PowerPoint. No executive summary that nobody reads. Just the facts.

Don't Make These Mistakes

Don't trust the documentation. That wiki page was last updated in 2021. Verify everything.

Don't do this alone. Talk to developers. Talk to ops. Talk to the person who gets paged at 3 AM. They know where the bodies are buried.

Don't take forever. This should take 1-2 days, not 3 months. You're assessing, not solving. Yet.

Don't skip the boring parts. Counting EC2 instances isn't fun, but it's necessary. You can't modernize what you can't see.

What's Next?

Now you know what you have. Next comes the hard part: deciding what to do with it.

What do you migrate first? What do you retire? What do you leave alone because it works and nobody wants to touch it?

But that's a problem for next week.

For now, go open that AWS Console and start clicking around. You might be surprised (or horrified) by what you find.

And hey, at least you'll finally know what you're dealing with.

The Boy Scout Rule (Yes, It Applies to Node.js Too)

Yeison Cruz — Tue, 27 May 2025 19:17:02 +0000

You’ve probably heard this one before: "Leave the campsite cleaner than you found it."

Well, surprise—this isn't just good advice for the outdoors. It’s also solid advice for writing code. And yeah, it has a name: The Boy Scout Rule.

🧼 What Is It?

The rule is simple: every time you touch some code, make it a bit better than it was.

You don’t have to refactor the entire project or go full-on DDD (Domain-Driven Drama™). That’s not the point. It’s about the little things.

If you see a variable named a that’s actually a userId, rename it.

If you stumble upon a 200-line function and you can extract 10 lines into a helper—do it.

If there’s a TODO from 2019 that’s now obsolete—delete it.

It’s like brushing your teeth. Nobody’s gonna throw you a party for it, but if you don’t do it... things get ugly fast.

🤔 Why Should You Care?

Because you’re not the only one reading that code. And your future self? They’ll thank you for not leaving landmines behind.

Tech debt builds up fast, and this rule is a low-effort way to fight it.

If everyone on your team improves just a little bit of the code they touch every day, the codebase evolves instead of rotting.

🛠️ How to Apply It in Node.js

Let’s get practical. You’re working on a Node.js project and need to fix a bug or add a feature. Before you close the file, ask yourself:

Can I rename this confusing function?
Are there console.log statements I should clean up?
Is this async/await spaghetti that could use a .catch()?
Can I add a missing comment that would help the next dev?

🔍 Before

function d(a, b) {
  return a + b;
}

🔍 After

function sumPrices(priceA, priceB) {
  return priceA + priceB;
}

💭 Final Thoughts

The Boy Scout Rule is not a framework, library, or fancy design pattern.
It’s a mindset.

It’s how you slowly improve a messy codebase without having to stop everything and “clean it all up.”

So the next time you touch a file, don’t just fix the bug or add the feature.
Do one nice thing for the next dev (even if that dev is you in 3 months).

Refactor that weird loop.
Rename that vague variable.
Delete that 2018 TODO.

Just make the campsite a little cleaner than you found it.

Tips para un mejor daily meeting

Yeison Cruz — Fri, 26 Feb 2021 22:42:58 +0000

A lo largo de mi carrera como desarrollador he estado en muchos equipos donde adoptamos algunas practicas de Scrum que nos pueden ser útiles, entre ellas esta el daily meeting.

Es importante recalcar que lo mencionado en este post son recomendaciones netamente personales

Y para tener un poco de contexto acerca de lo que es esta reunión, adjunto una descripción de Google.

El objetivo de esta reunión es facilitar la transferencia de información y la colaboración entre los miembros del equipo para aumentar su productividad, al poner de manifiesto puntos en que se pueden ayudar unos a otros.

Y vaya que es difícil lograr un Daily meeting efectivo (productivo). Siempre nos encontramos con personas que tienen una idea errónea de él, piensan que el daily meeting es una reunión para demostrarle al equipo que SI estoy trabajando, si estoy haciendo algo y que no estoy solo "calentando silla". Resulta que no es así, por este tipo de cosas se debería preocupar otro tipo de personas y se debe tratar en otras reuniones.

El objetivo de la reunión es facilitar la colaboración entre los miembros del equipo, ver si estamos desarrollando la tarea por el camino correcto, ver si alguien tiene una mejor solución al problema que tengo actualmente, o simplemente si alguien tiene un consejo acerca de mi tarea, como tal (Facilitar la colaboración).

Otro problema común es que seguimos pensando como desarrolladores, asumimos que las demás personas presentes están al tanto de cada actualización de mis tareas y terminamos hablando de puros tecnicismos que son muy difíciles de comprender. A fin de cuentas esto lo podríamos resolver dando un poco de contexto de la tarea justo antes de empezar a hablar.

Mi tarea actual es X y la finalidad es Y. De este punto en adelante hablaremos de las 3 preguntas basicas (¿que hice ayer?, ¿que voy hacer hoy?, ¿que obstaculos tuve o tengo?)

Es importante que si estamos en remoto, tengamos nuestras cámaras encendidas, ayuda a evitar las distracciones. Y si no vamos a prestar atención a lo que los compañeros dicen, no estoy facilitando una colaboración y no tendría sentido estar en esa ceremonia.

Recuerda también omitir detalles que no serían relevantes en cuanto al modelo de negocio, e incluso detalles que no son relevantes para el equipo, por ejemplo:

Tuve que salir por un compromiso personal.
Tuve reuniones con administración.
Estaba explicandole al compañero nuevo algo sobre X tema.

Son datos que no se deben incluir en esta reunión, hay otros espacios para esto.

Por otro lado, en cuanto al tiempo, algunas empresas optan por tener un limite de tiempo, y personalmente creo que no está bien, porque es algo muy variable dependiendo del número de tareas que hice, que tengo y que voy a hacer, también depende de que tan grande es mi tarea y si el contexto que debo darles es un poco extenso. Recuerden que la idea de la reunión es que me puedan colaborar y nadie me podrá ayudar si no pude explicarme bien por falta de tiempo.

Y para finalizar, sería bueno tener un moderador, porque somos humanos y podemos equivocarnos algunas veces e irnos por otro camino, dar más detalles de los necesarios o muchos tecnicismos, entonces ahí es cuando esta persona nos indicará inmediatamente el rumbo que debo tomar.

Tip personal: Lee sobre el Lenguaje ubicuo en DDD, nos ayuda a dar una idea de cómo tener conversaciones pensando en todo el equipo y no solo en mi rol.

Si llegaste hasta acá, Gracias por leer este post.

Soy un programador entusiasta con un canal en Youtube, no olvides seguirme ;)
https://www.youtube.com/channel/UCOqIekrnMxaW-0wUtItSUsw

How to get Gmail API Token

Yeison Cruz — Tue, 17 Nov 2020 16:04:16 +0000

First of all, login using you google account.

To generate the token, follow the next steps:

Generate credentials.json from gmail page (next step)
Go to Gmail guide and generate the credentials file (just if you dont have one)
Create a folder to run the code mkdir gmail-generate.
create the quickstart file touch quickstart.php
Execute composer require "google/apiclient"
run php quickstart.php (file content is below)
Now in the folder path you have a token.json file

<?php
require __DIR__ . '/vendor/autoload.php';

if (php_sapi_name() != 'cli') {
    throw new Exception('This application must be run on the command line.');
}

/**
 * Returns an authorized API client.
 * @return Google_Client the authorized client object
 */
function getClient()
{
    $client = new Google_Client();
    $client->setApplicationName('Gmail API PHP Quickstart');
    $client->setScopes(Google_Service_Gmail::GMAIL_READONLY);
    $client->setScopes(Google_Service_Gmail::GMAIL_MODIFY);
    $client->setAuthConfig('credentials.json');
    $client->setAccessType('offline');
    $client->setPrompt('select_account consent');

    // Load previously authorized token from a file, if it exists.
    // The file token.json stores the user's access and refresh tokens, and is
    // created automatically when the authorization flow completes for the first
    // time.
    $tokenPath = 'token.json';
    if (file_exists($tokenPath)) {
        $accessToken = json_decode(file_get_contents($tokenPath), true);
        $client->setAccessToken($accessToken);
    }

    // If there is no previous token or it's expired.
    if ($client->isAccessTokenExpired()) {
        // Refresh the token if possible, else fetch a new one.
        if ($client->getRefreshToken()) {
            $client->fetchAccessTokenWithRefreshToken($client->getRefreshToken());
        } else {
            // Request authorization from the user.
            $authUrl = $client->createAuthUrl();
            printf("Open the following link in your browser:\n%s\n", $authUrl);
            print 'Enter verification code: ';
            $authCode = trim(fgets(STDIN));

            // Exchange authorization code for an access token.
            $accessToken = $client->fetchAccessTokenWithAuthCode($authCode);
            $client->setAccessToken($accessToken);

            // Check to see if there was an error.
            if (array_key_exists('error', $accessToken)) {
                throw new Exception(join(', ', $accessToken));
            }
        }
        // Save the token to a file.
        if (!file_exists(dirname($tokenPath))) {
            mkdir(dirname($tokenPath), 0700, true);
        }
        file_put_contents($tokenPath, json_encode($client->getAccessToken()));
    }
    return $client;
}


// Get the API client and construct the service object.
$client = getClient();
$service = new Google_Service_Gmail($client);

// Print the labels in the user's account.
$user = 'me';
$results = $service->users_labels->listUsersLabels($user);

if (count($results->getLabels()) == 0) {
  print "No labels found.\n";
} else {
  print "Labels:\n";
  foreach ($results->getLabels() as $label) {
    printf("- %s\n", $label->getName());
  }
}

AWS CDK First impression

Yeison Cruz — Thu, 22 Oct 2020 03:10:40 +0000

On July 2019 was released the AWS CDK a code-first library to define cloud application infrastructure.

The AWS CDK is a new software development framework from AWS with the sole purpose of making it fun and easy to define cloud infrastructure in your favorite programming language and deploy it using AWS CloudFormation.

The first thing that i realized is the AWS Cloudformation compatibility. every new written code is transformed to YML template, so almost everything in Cloudformation can be used here and that is really util.

There is really big advantage, and is the way you can create the application infrastructure, now you can use different languages as JavaScript, Python, Java, C# and also Typescript. And this is a really good feature because sometimes developers are not familiarized with YAML structure's and JSON is not the best way to create a Cloudformation template, so now you will choose your preferred language and just start to create the needed resources using the library.

And now as the resources are created using code, you can create unit test to improve the quality and make sure a new developer is no going to change something important there.

With CloudFormation, you also can write some tests, but it requires another tool

Ok, now let's talk about constructors, is a new introduced concept and are so useful because now you won't need to create a lot of unnecessary as you usually do in YAML, just "WRITE LESS AND DO MORE", for example We need to write around 1000 lines of code using CloudFormation, when we try with AWS CDK, we only need to write around 50 lines of code.

// DynamoDB table constructor
new Table(scope: Construct, id: string, props: TableProps);

// This represents a single EC2 instance.
new Instance(scope: Construct, id: string, props: InstanceProps)

// Creates a new EBS Volume in AWS EC2
new Volume(scope: Construct, id: string, props: VolumeProps)

CDK vs YAML

More good things, the deployment process is a little bit friendly and request some confirmations before deploy.

Also you can see the updated resources easily after deploy.

There is something that personally is bad, and is the way to run the application locally. You can't do it using AWS CDK, you have to build the code to YML and execute it using AWS SAM, so you will need and step more before try every new change locally.

I hope this post has been useful for you.

Finally, you have a great Workshop here: https://cdkworkshop.com/

CDK use guide: https://docs.aws.amazon.com/cdk/latest/guide/home.html

Some examples: https://github.com/aws-samples/aws-cdk-examples

Write the README.md file, don't kill yourself

Yeison Cruz — Fri, 09 Oct 2020 03:12:48 +0000

It's so common for beginners !

Usually when we start a new project, we focus on the good part (the code), system logic, server configuration and that kind of thing, and completely forget some stuff like documentation, security, scalability, etc...

And Yes! also the README.md is completely forgotten, it's like a self stab, because we are humans and usually forget things, like the command to start the project, restrictions, how to deploy, how feature works, how to run tests and many more. Maybe you will say something like "Ok, I only work on this project, I can remember that kind of commands", but what about the other team members, what about NEW team members? they are going to lose a lot of time checking how to start, stop, test....

The README is going to make your life easier for you and every team member, and ins't a heroic task, it's as simple as created a file named README.md inside the project and that is all.

Even if you start to use the readme file, you can add more interesting things, like build status, deploy status and that kind of icons red/orange/green, unit test coverage and limits.

I used to assume that README was a file located at the root of a software repository. Did you know a README file serves as an index file in any directory of your versioned tree? It is pretty handy if you feel the need to split its content, or if you want to address specific needs for relevant folders of your projects.

And remember, README files are the entry points needs, to be focused in what is really needed.

You can use tools as Dillinger to write it easily.
https://dillinger.io/

Here are some examples :
https://github.com/matiassingers/awesome-readme

Feature toggles are not optional

Yeison Cruz — Fri, 11 Sep 2020 19:12:59 +0000

Here is the description from https://martinfowler.com/articles/feature-toggles.html

Feature Toggles (often also refered to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. They fall into various usage categories, and it's important to take that categorization into account when implementing and managing toggles. Toggles introduce complexity. We can keep that complexity in check by using smart toggle implementation practices and appropriate tools to manage our toggle configuration, but we should also aim to constrain the number of toggles in our system.

Ok, it's simple, you just need to create and if/else to determine if new/old block of code should be executed.

And now, why Feature Flags should not be optional ?.
it's because quality. We are humans and we can make mistakes, but is so expensive when you made a mistake inside payment area, deployed and go to rest, you are not able to change the code when it fails and somebody have to read the code, maybe rollback, but some other features can be affected because other team member already deployed, so not only your change will be restore, maybe other important functionality too.
it's a dead end road. When the team found a solution, the company have lost a lot of money.

You will need a way to just disable the new feature easily, but how ?, and here is when feature toggles are important, because any team member, even the customer can just go to a "features system" and just disable it in a while. In PRODUCTION site every minute counts.

That's is a good reason, but there are more reasons. Now just think a big functionality is's being develop in the protect, and there 3 developers working in different modules, but one of them (you) finish first, the main functionality still incomplete, so the code can't be deployed to production site, just keep the branch open until other team members finish, but when the full functionality is finished you will need to merge changes and maybe your expected block of code was changed by another team member and then you will have update the code again, fix conflicts and test again, that's a lot of time i think. A simple feature toggle can be the solution, you just need to write your code and if the dependencies are not complete you just turn off your feature toggle (to avoid the code breaks something in production) and just send your changes to master easily, on this ways the other team member will have your changes and your task it's done here, congrats!

Feature toggles also called featured flags. Can be implemented on very language just with and if/else, but you can improve it using ENV variables, database, external functionality or even your own, it's not complicated.

You can use featured flags conditions based on whatever you want ip, enviroment, host, zone, country, etc...

Basic example

if( useNewAlgorithm ){
   return enhancedSplineReticulation();
}else{
   return oldFashionedSplineReticulation();
}

Dynamic example

function reticulateSplines(){
  if( featureIsEnabled("use-new-SR-algorithm") ){
    return enhancedSplineReticulation();
  }else{
    return oldFashionedSplineReticulation();
  }
}

Here is a list of services that you can use.

As a personal advise, buy a feature flagging platform, don't build your own, it's because the goal here is make the code simple, let the hard work to experienced team.

And... Please remove the features after your code is running and validated. keep it as simple as possible.

Resumen para un DevOps day

Yeison Cruz — Sat, 08 Aug 2020 02:16:40 +0000

Después de escuchar a muchas personas durante dos días dando charlas acerca de DevOps, "¿que es?", sus inicios y "¿para que sirve?", logre sacar algunas conclusiones que espero les sean de ayuda para tener en cuenta al momento de hablar de DevOps.

Las deducciones o afirmaciones aquí mencionadas son netamente personales y tambien citaré algunas frases de los expositores.

imagen obtenida de este post https://twitter.com/DevopsdaysMed/status/1283219819496603648/photo/1

Daré inicio a este articulo citando la frase de Denovan Brown, "DevOps es la unión de personas, procesos, y productos para permitir una entrega continua de valor a los usuarios finales".

Desde este preciso instante ya podemos ver que hablamos de una filosofía más no de una lista de herramientas, administrador de servidores o un grupo de personas. Ahora empezamos a verlo desde otra perspectiva, ahora estamos hablando de una cultura tanto personal como organizacional con la finalidad de entregar más calidad en el menos tiempo posible.

Ahora, ¿porque una cultura?, porque DevOps le permite de los equipos y a las personas definir como van a interactuar unos con los otros incluso sin estar dentro de la misma área de trabajo.

Ya sabemos que es DevOps, pero ahora hablemos un poco de lo que no es:

Una persona encargada de administrar servidores.
Un listado de herramientas.
No es asunto de TI.
No es un area de la empresa.
y por último, hacer CI/CD no es hacer DevOps, esto va más allá.

Bien! Ya tenemos claros algunos conceptos, y podremos sacar provecho de algunos de los consejos brindados por estas personas.

"Una ficha de dominó puede derribar otra con un tamaño 50% mayor" (Lorne Whitehead).
Claramente podemos ver la importancia de tener siempre un desarrollo progresivo en nuestros proyectos, para el usuario final es mucho más valioso poder interactuar con un sistema básico HOY, mañana un poco mejor y pasado mañana aún mejor, que tener ALGO con más herramientas pero dentro de 1 año.

"No existen pequeños errores". Esto también se puede convertir en un efecto domino, cuando por ejemplo olvidamos cambiar una sola variable antes de ir a producción, pero resulta que esa variable es la que habilita el debug de todo el sistema.

"DevOps es un vehiculo cuyo único destino es la productividad". Ya sabemos que no lo podemos ver como simplemente un grupo de personas encargadas de administrar servidores, debemos verlo como ese conjunto de acciones que nos ayuden a mejorar, sí tener CI/CD mejora mi productividad entonces hace parte de DevOps, sí tener Contenedores Docker hace que mi forma de desplegar sea mucho mas rapida y entregar valor al cliente mas rapido entonces hace parte de DevOps. Y asi podemos continuar con el sin fin de acciones que nos hacer ser mas productivos.

"Microservicios son un camino a la productividad", divide y veceras, siempre sera mucho mas facil tener todo un proceso de calidad a un pequeño sistema que simplemente un complejo sistema de calidad a un gran poryecto. ¡No lo sé, Piensalo!

"No deje de lado los las pruebas automatizadas". No somos perfectos y con consigueinte nuestro software tampoco lo sera, sí sabemos que nuestro software va a fallar, pues entonces que falle rapido y en nuestras manos, asi sera menos costoso dar soporte y generar mas valor. Además, esta en nuestra humanidad, Fallar + Aprender = Crecer.

"Things that have never happened before, happen all the time". No se preocupe, siempre vamos a tener algo que no sabemos como resolver, pero de eso se trata DeVops, prepararnos para evitar los fallos y cuando falle tengamos una mejor idea de que podemos hacer. Metricas, Rollback, Logs, Upgrades, Autoscaling, system recover...

"Jenkins está obsoleto", Naturalmente no es que sea una mala herramienta, aun lo es, y no tengo nada en contra, pero si lo pensamos bien, es una herramienta a la cual le tenemos que instalar y dar soporte. Administrar nuestra aplicacion ya es bastante carga como para que tengamos una preocupacion más, ahora tenemos algunas alternativas mas escalables como Github actions, Buddy.works, Gitlab, circle ci, codefresh.io, aws codepipeline, google cloud build y muchas mas.

"No matter how much we prepare... We really don't know very much". ¿Que?, ¿Como?, ¿Donde?, ¿Cuando?, no importa lo que hagamos, siempre vamos a tener alguna falla o algo por mejorar, lo importante es que trabajemo en reducir esa posibilidad tanto como sea posible, se mencionó mucho
'Ingeniería del caos' y como ha sido la clave para mejorar.

"¿Porque las personas ponemos resistencia?", Es normal y siempre va a pasar, cuando crear practicas DevOps va haber resistencia, pero eso tambien es parte del proceso, una vez mas es escencia del ser humano, entonces lo unico que podemos hacer es ser pacientes y buscar la alternativa para que estas practicas sean bien acojidas.

Hasta aca, he logrado hacer un resumen de algunas notas que tomé y de otras cosas que me acuerdo, la verdad es que fue un dia muy productivo y espero que estas notas les sean de utilidad.

Dejaré algunos posts a continuacion.

// Detect dark theme var iframe = document.getElementById('tweet-1291529103347253248-338'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1291529103347253248&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1291528352457777154-876'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1291528352457777154&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1289234402891853824-396'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1289234402891853824&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1289249973565964289-160'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1289249973565964289&theme=dark" }

https://twitter.com/DevopsdaysMed/media

What about scalability?

Yeison Cruz — Thu, 30 Jul 2020 01:07:48 +0000

Let me tell you, it's beautiful

Systems are expected to grow at any time, and you know "Any time" even at middle of night. Also you won't know when a new pandemic is going to be propagated in the world and people need to make almost everything using the computer and your system will increase traffic even 500% of the expected.

It sounds good, but be careful scalability isn't something you have to do just when the system fails or maybe when a big deal is near. You have to think is scalability from the beginning. Because is so difficult to scale in/out a monolith, here is a list that i think you should have in mind from the beginning:

Don't create logs in the server, it's difficult to maintain when you have to duplicate your server.
Avoid a LAMP, MEAN servers, please move your database to another connection.
Integrate a monitoring tool, will be easy if you can see what is happening before sign in into the server.
Create Microservices, and avoid to use always the same programming languages, there is a language according the task.
Use external service for assets (img, pdf, csv, txt ...), I usually use S3 it's cool.

After follow those tips, will be easier to move your system to a high scalable site, and some other benefit come in the package like easy to maintain, availability, cost effective site. Yes if you are able to reduce the server size when there are no users using it your wallet will be happy.

And at the end, obviously you will be able to sleep better.