What Does a DevOps Engineer Actually Do in a Cloud Project?

Recently, while having some iced tea with a few DevOps friends, we ended up having a pretty interesting discussion about DevOps on Cloud versus DevOps on-premise. One question that kept coming up was: What does a DevOps Engineer actually do in a Cloud project?

DevOps VietNam is an ecosystem that has long supported engineers and businesses in growing together with the industry in Vietnam through many meaningful activities, as most of you already know. As for me, I’m just someone who keeps an eye on servers, lucky enough to have publishing access here, so I thought I’d share a bit of my personal perspective from nearly 10 years in the field.

Since this is a personal opinion, though to be fair I also picked up quite a bit from other Senior engineers during that discussion, some of you may nod along while others may completely disagree. But I haven’t seen anyone write about this yet, so I figured I’d give it a shot. Hopefully I can hear more perspectives from you as well, and maybe help those who still don’t have a clear picture of the role.

What Does DevOps Do When a Project Starts?

Let’s start right at the beginning of a project.

Imagine a product team building a system with several APIs, background workers, PostgreSQL, and the team has decided to deploy everything on AWS.

At this point, in my opinion, DevOps should not simply receive the requirements and immediately start creating VPCs, EC2 instances, or an EKS cluster.

The first thing is to understand what components the application has, how they communicate with each other, and what the requirements are around availability, security, scalability, and data recovery. At the same time, we also need to understand the project’s budget, operational capabilities, and regulatory requirements.

From that information, DevOps works together with the Architect and Development team to choose and design an appropriate Cloud platform.

For example, should the application run on EC2, ECS, or EKS? Should the database use RDS or be self-managed? How should the network be segmented and access controlled? If one Availability Zone goes down, which components must remain operational?

Once the approach has been agreed on, DevOps implements the infrastructure, configures networking and IAM, manages secrets, sets up environments, and uses Infrastructure as Code to manage those resources.

So, in my opinion, the expected outcome at this stage is a Cloud platform where the application can be deployed, managed consistently, changed when needed, and operated according to the technical requirements that were defined.

There is another point here that I think is worth discussing: technology selection.

Just because you know how to build an EKS cluster does not mean the project needs EKS.

A small team with only a few services might operate much more effectively on ECS Fargate. Forcing everything onto EKS just to look “professional” may introduce a lot of unnecessary risk.

On the other hand, if the organization already has a Kubernetes platform, the team has enough operational capability, and the project needs to scale in complexity, then EKS may be a perfectly reasonable choice.

The important question is not which technology is more modern. The important thing is understanding which requirements and tradeoffs lead to the decision, then balancing the pros and cons before choosing.

Anyway, life is basically an endless chain of choices and decisions 😀

What Does DevOps Do When Developers Start Releasing?

Now we have the infrastructure.

But Developers cannot keep sending Docker images to DevOps every time there is a release and asking someone to deploy them manually.

At this point, DevOps needs to build the process that moves changes from source code into production.

The work may include CI/CD pipelines, artifact building and management, security checks, environment specific configuration management, deployment strategies, and rollback mechanisms.

But we need to look a little deeper than that.

What if the pipeline deploys successfully but the new version contains a bug?

What if we need to roll back the application, but the database has already run a migration that is not backward compatible?

What if a deployment fails halfway through? Can the system continue serving users?

These are situations that cannot be solved simply by writing a pipeline.

DevOps needs to work with Developers to agree on how releases should happen, how changes are controlled, and what should happen when a deployment goes wrong.

So, in my view, the expected outcome here is that Developers can move software into production through a clear, repeatable, controlled process without depending too heavily on manual actions from one particular person.

In other words, DevOps is not hired to deploy code on behalf of Developers forever.

Part of the DevOps job is to build the capability that allows the team to do it themselves safely.

What Does DevOps Do Once the Application Is in Production?

This is where all the earlier decisions start getting tested in the real world.

An application being able to run does not necessarily mean it can be operated properly.

DevOps needs to help build observability, alerting, backup, recovery, capacity management, and the processes required to operate production systems.

For example, imagine that one day the system starts returning a large number of 5xx errors.

Kubernetes is still healthy. CPU and memory look completely normal.

But the database connection pool has been exhausted because the number of requests suddenly spiked. A number of other authors here have already shared similar cases.

If we only monitor infrastructure resources, it can be very difficult to see the actual cause.

That is why, in addition to CPU, memory, and network metrics, the system also needs application metrics, logs, traces, and indicators that reflect how the service is actually behaving.

When an incident occurs, DevOps may participate in narrowing down the cause, checking infrastructure, supporting rollback, adjusting resources, or working with Developers to solve application level issues.

One thing I think is important to understand is that just because something breaks in production does not mean DevOps has to fix everything.

But the mechanisms for detecting, diagnosing, and recovering the system need to be prepared in advance.

Likewise, successfully configuring a backup does not mean the data can definitely be restored.

If you have never tested a restore, you still do not really know how recoverable the system is.

So by this point, I think the expected outcome is a system that does not just run under normal conditions, but can also detect, handle, and recover when things do not go as expected.

Once the System Is Stable, What Else Does DevOps Do?

This is another part I think is worth talking about in Cloud projects.

Some people say Cloud is basically ready-made stuff, so what is there to be difficult about?

I really don’t like this point of view. Either they have never actually worked across the full scope of a project, or they have not gone deep enough into Cloud.

The job does not end once the infrastructure is up, CI/CD is working, and monitoring is in place.

After the system has been running for some time, new problems begin to appear.

Developers spend too much time waiting for environments to be created.

Deployments still have too many manual steps.

Resources are overprovisioned.

The Cloud bill keeps increasing, but no one is quite sure where the money is actually going.

Some components made sense when the project started but are no longer appropriate.

So I think DevOps needs to continuously evaluate and improve these areas.

Sometimes that means building self-service infrastructure so Developers can be more independent.

Sometimes it means improving pipelines, standardizing configurations, optimizing resources, or adjusting autoscaling mechanisms.

On Cloud in particular, cost becomes one of the top considerations. We all understand that one. Money hits close to home 😀

A system can meet all the requirements for performance and availability, but if the operating cost is far beyond what the project can afford or actually needs, then no matter how beautiful the architecture looks, it is going to be difficult to get approved.

At the same time, optimization does not simply mean reducing the bill.

Cutting database costs in half while significantly increasing the risk of downtime is not a good decision in my book.

I think the responsibility here is to continuously improve the balance between operability, reliability, security, cost, and product development speed.

Kind of like the Middle Way in Buddhism. Too much of anything is usually not good 😀

And if we want to know whether those improvements actually work, we need to look at measurable outcomes.

Did deployment time go down?

Are incidents detected and recovered from faster?

Are Developers less dependent on manual operations?

Does the cost actually match the project’s needs?

If we cannot measure the change, it is very easy to fall into the trap of adding more tools without knowing whether the system has actually improved.

So What Is the Core Job of a DevOps Engineer?

When it comes to the mindset and actual work of DevOps, it honestly feels a bit like trying to keep everyone happy at once.

We still talk about the same familiar tasks and technologies, but everyone has different experiences, every company has a different culture, and in my opinion no single article can fully satisfy everyone.

However, based on my own experience looking across the full lifecycle of a Cloud project, I would summarize the work of DevOps like this:

• During the build stage: DevOps participates in designing, implementing, and managing the Cloud platform so the application has an appropriate environment to run on.
• During development and release: DevOps builds automation mechanisms that help Developers test, deploy, and change applications safely and consistently.
• In production: DevOps builds and maintains capabilities for monitoring, operations, incident response, and system recovery.
• Throughout the project lifecycle: DevOps continues improving the platform, reducing manual work, controlling risk, and optimizing the use of Cloud resources.

And as I mentioned earlier, depending on the organization and its scale, these responsibilities may be shared across DevOps, SRE, Platform Engineering, Security, and Development teams.

It does not mean one DevOps Engineer has to do everything alone.

But if the question is what DevOps contributes to a project, I think these are fairly concrete areas of responsibility and outcomes that we can look at.

Conclusion

Coming back to the original question of DevOps on Cloud versus DevOps on-premise, I do not think the goals or the fundamental nature of the work are that different.

What changes is the environment, the tools, the constraints, and the technical decisions we have to make.

Cloud allows us to provision resources quickly, use managed services, and automate at large scale.

But along with that come challenges around access control, usage based costs, configuration management, shared security responsibilities, and system complexity.

That is why a DevOps Engineer working with Cloud should not only know how to use Cloud services.

They also need to understand how to combine and operate those services as a platform that supports the software development process.

So if I had to answer the question, “What does a DevOps Engineer actually do in a Cloud project?”, I would say:

They participate in building and maintaining the technical capabilities that allow applications to be deployed, changed, operated, and recovered reliably on the Cloud.

If you skipped everything above and only read that summary, it probably sounds exactly like some kind of corporate slogan 😀

Terraform, Kubernetes, AWS, and CI/CD are tools and technologies we use to do that work.

Knowing how to use the tools is one skill.

Knowing how to design and combine them into a system that actually fits the project is another capability entirely.

And I think it is in that second part where a DevOps Engineer’s experience and engineering mindset really start to make the difference between one level of expertise and another.