Cloud Native Journey

The journey toward Cloud Native doesn't happen overnight. It is made of consistent steps, well-thought-out architectural choices, and, above to all, continuous learning. Here at Getup, this journey has been part of our daily routine for quite some time, guiding technical, organizational, and cultural decisions. And now, the time has come to share this path with the world.

In this blog post, you will follow, stage by stage, the framework we use internally to guide teams in adopting Cloud Native practices, focusing on pragmatism, results, and continuous maturity. Every week, this post will be updated with a new video explaining the details of each phase of the journey, always with real examples, recommended tools, and applicable insights.

We drew inspiration from established frameworks such as DORA Metrics, Accelerate, CALMS, and other maturity models, but we went further: we transformed this theory into a practical approach, ready to be adapted by teams of all sizes and maturity levels.

Whether you are starting, advancing, or even rethinking your Cloud Native strategy, this series was made for you. This is our journey, and we want to travel it together with you.

We begin our Cloud Native journey with what really matters: the foundation. In this first chapter of KubiDrops, we break down the technical and strategic foundation needed to start well. We talk about containerization, scalable architecture, security best practices, and versioning, always with a direct and applicable approach.

What is this so-called foundation?

The foundation is the set of decisions and practices that sustain the entire journey. If you haven't containerized your applications consistently, if you are still unsure about how to structure your images, if your Git Flow is more like Git Chaos, you need to stop here and resolve this before thinking about any next stage.

Containers are just the beginning

We talk about the use of containers, of course. But also about why Kubernetes, with a capital K, makes sense in scenarios that demand resilience and scale. If your environment still depends on manual deploys, it is time to automate with good practices and reliable pipelines.

Security, ARM, and Git

We discuss practices such as using lightweight distros like Alpine to reduce attack surfaces and how adopting ARM architecture can generate up to thirty percent savings in infrastructure. We also highlight the role of Git as a pillar of versioning and collaboration. It's not just a tool; it's team culture.

The foundation is technical, but also financial

Every technical choice has an impact on the business. More deploys per day, lower downtime, a more productive and predictable team. This needs to be understood by the entire team, including managers. True Cloud Native is everyone's conversation.

Want to know how to start building a solid foundation? Watch the full episode on YouTube

In the second episode of KubiDrops, we dive headfirst into Infrastructure as Code, the famous IaC. But take it easy, IaC is not just about creating machines with Terraform. It is about transforming infrastructure into a trackable, versionable, auditable, and consistently manageable system.

Foundations first

Before thinking about spinning up Kubernetes, you need to firmly define your cloud foundation. VPCs, Subnets, Security Groups, all as code. There's no use doing ClickOps today and regretting it tomorrow.

IAM, Networking, Storage

We show how IAM policies should follow the same principle. Created as code, with separation of duties and least privilege. We also talk about the importance of treating network and storage with the same seriousness. VPC is not just for connecting services; it's where the security of your infrastructure lives.

Git, observability, and DR

We talk about the importance of versioning everything. Seriously, everything. IAM, Prometheus, backups. Because versioning is sharing. Because versioning is scaling. Because versioning gives you vacation days. And of course, we talk about Disaster Recovery. If your plan depends on remembering how to configure something in the console, it is not a plan.

Benefits that make sense

Automation and standardization directly impact onboarding time, team confidence, and environment stability. With this, you reduce lead time, improve delivery, and gain predictability. More than that, it allows more people to collaborate safely.

Continuing our cloud native journey, this week's Kubidrops dives into one of the most transformative concepts of modern operation: GitOps. But after all, why has this approach been so valued by engineering and operations teams? Let's get straight to the point.

Start by measuring

Before you go out creating repositories or choosing tools, the first step is to measure where you are. Without a clear thermometer, it is difficult to prioritize tasks, justify investments, and choose the best paths. GitOps is not a goal, it is a means — and it needs to be adopted strategically.

A well-done bootstrap is half the battle

One of the initial pillars of GitOps is having an automated and standardized bootstrap. Scripts and templates are your allies to ensure that every new environment starts the right way. This accelerates delivery and reduces rework.

Shared culture matters (and a lot)

More important than the tool is how it is adopted. Documenting best practices, training the team, sharing learnings, and keeping workflows consistent are fundamental steps for the success of GitOps in your organization.

Infrastructure as true code

Using tools like FluxCD and ArgoCD to manage infrastructure via Git allows total control over changes. Everything goes through pull requests, with history, review, and rollback ready for use. This strengthens governance and the reliability of your environment.

GitOps for applications: beyond deployment

Applications also join the game. Automating building, testing, security, and deployment via pipelines brings consistency and speed. All this with versioned configurations, adapted by environment, and maintained under the same Git-first model.

Why prioritize GitOps?

The gains are concrete: more deploys per day, fewer risks, fewer repetitive tasks, and more time for strategic initiatives. Team productivity increases because operation stops being a bottleneck and becomes a differentiator.

In the Cloud Native Journey, it is not enough to scale, deliver fast, or be efficient: you must be secure. And we are not talking about a generic or inspirational "security." In this article, we will address directly and technically the critical points you need to consider to protect your environment in a concrete way.

We start with the basics: visibility. This means scanning your Kubernetes clusters for misconfigurations and vulnerabilities. Tools like Trivy, Grype, and Docker Scout are great allies. And here is a golden tip: do not underestimate configuration errors. They are the silent culprits of many breaches.

GearUp, in fact, developed Marvin, a tool that compiles best practices from CIS, NSA, and other security standards, even allowing you to write your own rules. This allows you not only to scan but also to measure your evolution over time.

In execution (runtime), tools like Falco are essential to detect abnormal container behaviors. A "secure" image is of no use if it acts like a compromised bot when it enters production.

Managing access is also a fundamental pillar: monitoring RBAC, reviewing permissions with plugins like Hen, and configuring audit logs help understand who did what and when.

Keeping your cluster updated is a defense strategy. Operating at most three versions behind prevents unpleasant end-of-support surprises or known exploits.

On the sensitive data protection side, adopting a good secrets manager like Vault is mandatory. Simply hiding secrets in YAML is not enough.

For security policies, it's worth exploring the power of Kubernetes' CEL (Common Expression Language). With it, you can apply everything from admission policies to resource limits, preventing failures and exhaustion due to misuse. All this with native automation, increasing reliability and reducing dependence on specialists.

Another critical point is the use of secure images. This means using trusted bases, signing and verifying those images, and, if possible, generating an SBOM (Software Bill of Materials) to ensure integrity.

And for those who think security is a cost: think again. Proactively investing in protection reduces recovery costs, mitigates legal risks, and improves your company's reputation. Safer environments are more reliable, scalable, and build more customer trust.

Finally, if you scan your clusters and find recurring vulnerabilities in basic images, know that GearUp is working on a hardened images program to reinforce security from the ground up.

The journey is cloud native, but security has to be by design.

Observability in practice: how to provide real visibility to your Cloud Native environment

In the cloud native journey we are building together, it's time to talk about a topic that goes far beyond nice graphics and colorful dashboards: observability. In this Kubidrops, we get into the heart of what it actually means to have control and visibility of your environment — and why this matters much more than it seems.

Observability is not monitoring

Many people confuse the two, but observability is about understanding why something went wrong, not just knowing that something is wrong. This requires going beyond the basics. The triad of logs, metrics, and traces remains fundamental, but it must be used strategically and in an integrated way.

First practical steps

Start with the tools you already know, but with a new perspective. The proposal here is not to adopt the most expensive or sophisticated solution, but to build a baseline that allows detecting anomalous behavior, correlating events, and reacting quickly. The secret is in the culture and integration.

Right team, right alerts

Observability is not about alerting on everything. It is about alerting on what truly matters, to the right people. Creating well-defined business rules and SLOs is the first step to having a stable environment — without alert fatigue or unpleasant surprises in the middle of the night.

Tools and practices

In this episode, we cite approaches and tools like Prometheus, Grafana, Elastic, OpenTelemetry, and the importance of clear patterns and agreements between teams. If each squad observes in their own way, nobody sees the big picture. Standardization here is the ally of efficiency.

Real benefits

With good observability, your team gains time, confidence, and predictability. The environment becomes a reliable source of data for technical and product decisions. Less guesswork, more precision.

Conclusion

Whether to prevent problems, reduce MTTR, or evolve your operation, investing in observability is inevitable for anyone who wants to operate at scale. Start now with what you have — the important thing is not to operate in the dark.

In our path toward Cloud Native adoption, we reached the critical stage of FinOps — the intersection between finance and operations that allows us to balance agility and budgetary discipline. In this post, we share practical insights discussed in the Kubidrops episode, showing how to structure effective cost governance and transform consumption data into strategic decisions.

Cost Visibility with Tags and Labels

We start by talking about the importance of granularity in tracking expenses. Without a robust strategy of tags and labels to map each resource to an application, team, or environment, we risk being in the dark when the invoice arrives. Our recommendation is to standardize nomenclatures, define automatic assignment policies, and periodically review tag coverage, ensuring that each namespace and workload is aligned with clear cost centers.

Continuous Resource Optimization

Having visibility is just the first step. The practice of right-sizing, adjusting CPU and memory requests and limits based on actual metrics, prevents overprovisioning. We combine bin-packing techniques and well-calibrated autoscaling configurations to maximize node occupancy without sacrificing performance. We also reinforce the cleaning up of orphan volumes, IPs, and images: forgotten items in the cloud can become budget villains.

Dashboards and Alerts for Financial Control

To anticipate deviations, we build dashboards that aggregate cost metrics into existing observability panels. This allows us to correlate usage spikes with feature releases or load tests. We define anomaly alerts — for example, when a single deploy triggers a sudden increase in spending — and transform financial notifications into operational triggers, avoiding last-minute surprises.

Culture of Showback and Chargeback

Promoting shared responsibility requires transparency: showback practices present consumption reports to each team, while chargeback makes those who generate the expenses financially responsible. We discussed how to involve product and finance leaders from the beginning, creating feedback loops where teams start to optimize costs as part of their continuous delivery.

Budget Predictability

With visibility and optimization up to date, we move forward to expense forecasting. We use simple projection models based on historical growth and seasonality, adjusting quarterly budgets and reviewing them before each financial cycle. The discipline of reviewing forecasts avoids sharp cuts — and maintains trust between engineering and finance teams.

Next Steps and Resources

To deepen your knowledge, check out our video on security and observability, where we address advanced metrics integrations. Also, take advantage of the coupon GETUP15 for a discount on registration for MindSec and continue your Cloud Native journey focused on cost, performance, and security.

Every Tuesday at 10 am, a new stage of our journey goes live!

Also follow the playlist on YouTube and the presentation/slides are available here.

Discover how we are rethinking container security at ▸ getup.io/zerocve