Cloud Engineer

At TecCentric, I worked on cloud migration and application modernization projects for clients moving from traditional on-premise infrastructure into Google Cloud Platform.

My work focused on designing and supporting hybrid-cloud architectures, migrating workloads and data into GCP, deploying web applications onto managed compute platforms, configuring cloud networking, and designing environments that could scale dynamically based on traffic.

Across the internship, I contributed to migrations for more than 10 client environments and helped deploy and scale more than 10 client-facing web applications using technologies including:

• Google Kubernetes Engine (GKE)
• Google Compute Engine (GCE)
• Google App Engine
• Google Cloud Networking
• Google Cloud Storage
• load balancing
• autoscaling
• hybrid-cloud connectivity

The goal was not simply to move servers into the cloud. The broader objective was to help clients redesign their infrastructure so that compute, storage, networking, and application delivery could take advantage of the scalability, resilience, and managed services available within GCP.

Migrating on-premise infrastructure to Google Cloud

A major part of my role involved helping clients transition workloads from traditional on-premise data centers into hybrid Google Cloud environments.

Most migrations began by understanding the client's existing infrastructure. That meant identifying:

• applications currently running on physical or virtual servers
• application dependencies
• databases
• storage requirements
• network topology
• internal services
• expected traffic
• compute requirements
• security restrictions
• which systems could move immediately
• which systems needed to remain on-premise

Rather than assuming that every workload should immediately become cloud-native, we evaluated how each application could best fit into GCP. Some workloads could be containerized and deployed through Google Kubernetes Engine. Others were better suited to virtual machines running on Google Compute Engine. More lightweight or managed web workloads could be deployed using Google App Engine.

This allowed the architecture to be selected according to the requirements of the application rather than forcing every client into the same deployment model.

Hybrid cloud architecture

Many migrations could not happen as a single cutover from an on-premise data center to the cloud. Clients often still had internal systems, databases, storage, or applications that needed to remain inside their existing infrastructure while newer workloads operated inside GCP. That required designing a hybrid-cloud architecture.

Conceptually, the environment looked like:

The objective was to allow cloud workloads and existing enterprise systems to communicate securely while gradually reducing dependency on the original data center.

This also allowed migrations to occur incrementally. Instead of requiring the client to shut down an entire legacy environment and migrate everything at once, workloads could be moved and validated in stages.

Google Cloud networking

Networking was an important part of every migration because moving an application to GCP is not useful if the application cannot communicate securely with its dependencies. I gained experience working with concepts within Google Cloud Networking, including:

• Virtual Private Clouds
• subnets
• private IP addressing
• firewall rules
• routing
• ingress and egress traffic
• public versus private services
• load balancing
• hybrid connectivity
• DNS and service accessibility

The network architecture had to control which systems could communicate while still allowing the applications to operate correctly. For internet-facing applications, traffic needed to reach the appropriate frontend or backend service without directly exposing unnecessary internal resources. For internal workloads, communication could remain within private network boundaries.

This gave me practical exposure to designing cloud infrastructure around both connectivity and security, rather than simply deploying compute resources.

Application modernization with Google Kubernetes Engine

For applications that could be containerized, I worked with Google Kubernetes Engine to deploy and operate them as scalable workloads. Instead of running an application as a single process on a fixed server, the application could be packaged inside a container and deployed into a Kubernetes cluster.

The architecture then became:

This introduced several advantages compared with traditional infrastructure. Application instances could be recreated automatically if a pod failed. Multiple replicas could run simultaneously. Traffic could be distributed across healthy instances. And the number of application instances could increase or decrease depending on workload.

I worked with environments where client web applications needed to remain responsive under high levels of concurrent traffic. Rather than provisioning infrastructure based solely on the highest possible traffic level, GKE allowed the environment to dynamically adjust capacity.

Horizontal autoscaling

One of the major advantages of Kubernetes-based deployments was horizontal scaling. If application load increased, additional pod replicas could be created. If traffic later decreased, unnecessary replicas could be removed. Conceptually:

• normal traffic → two application replicas
• traffic spike → five application replicas
• heavy concurrent load → additional replicas created
• traffic decreases → replicas scale back down

This allowed infrastructure resources to better follow actual application demand. Autoscaling helped improve availability, because additional application instances could handle increased load, and cost efficiency, because clients did not need to permanently provision infrastructure for peak traffic.

This was especially useful for applications where traffic patterns could vary significantly throughout the day or around major events.

Compute Engine workloads

Not every workload could immediately be containerized. Some client applications depended on traditional operating-system environments, existing binaries, or server-level configuration. For these cases, Google Compute Engine provided virtual-machine infrastructure within GCP, which allowed clients to migrate traditional server workloads while still gaining benefits from cloud infrastructure.

Depending on the workload, these environments could be configured with:

• appropriate machine types
• persistent storage
• private networking
• firewall rules
• external connectivity
• startup configuration
• monitoring
• scaling strategies

This made GCE particularly useful during cloud migrations where modernization needed to happen incrementally. A legacy workload could first be migrated onto cloud infrastructure before eventually being redesigned into a more cloud-native architecture.

App Engine deployments

For web applications that did not require direct management of Kubernetes clusters or virtual machines, I also worked with Google App Engine. App Engine provided a more managed deployment model where the platform handled much of the underlying infrastructure. This made it suitable for applications where the priority was:

• straightforward deployment
• automatic scaling
• simplified infrastructure management
• high availability
• managed application hosting

Working across App Engine, Compute Engine, and Kubernetes helped me understand that running something in the cloud can mean very different architectural approaches. The correct deployment model depends on the application's requirements, operational complexity, scaling patterns, and level of infrastructure control required.

High availability and traffic management

A key requirement for many client-facing applications was ensuring that the system remained available when traffic increased. Instead of depending on a single application server, cloud environments could distribute incoming requests across several healthy instances.

For containerized workloads, this meant running multiple replicas behind Kubernetes services and load-balancing infrastructure. For other deployments, GCP load-balancing and autoscaling capabilities could distribute traffic across application instances. The objective was to avoid architectures where one overloaded server became a single point of failure.

The general principle was:

This gave the applications much greater resilience during traffic spikes.

Qatar Football Association: cloud data migration

One of the more interesting client environments I was exposed to involved the Qatar Football Association. The organization had accumulated a large amount of video data within its existing on-premise infrastructure, including football footage associated with major competitions such as the FIFA World Cup.

Maintaining a large media archive exclusively on-premise creates several limitations. Video requires significant storage capacity, and large datasets can become difficult to scale, process, share, and analyze when they remain tied to local data-center infrastructure.

The migration initiative involved moving that video data away from a primarily on-premise architecture and toward Google Cloud. The goal was not only to improve storage scalability. Moving the footage into cloud infrastructure also created the foundation for future data analytics and AI-based video processing. Rather than keeping video as passive archived data, a cloud-based architecture could allow the organization to eventually use that footage as an analytical dataset.

Designing the QFA environment for AI-ready video data

The architectural idea behind the migration was to separate large-scale media storage from the compute resources used to process it. Conceptually:

This type of architecture is much more flexible than storing video directly on individual application servers. The raw footage could live inside highly scalable object storage while compute resources were provisioned only when analysis was required.

That separation between storage and compute is a fundamental cloud architecture principle. Instead of purchasing enough permanent server capacity to process the entire archive, cloud compute could be scaled according to the amount of work being performed.

Enabling future football analytics

The value of moving QFA's video archive to the cloud extended beyond infrastructure modernization. Once video data exists in scalable cloud storage, it becomes possible to build analytical pipelines around it. Potential football-analysis workloads could use video to extract information such as:

• player movement
• positioning
• formations
• possession patterns
• recurring tactical patterns
• player involvement
• game events
• training footage comparisons
• historical match analysis

The migration therefore created an infrastructure foundation where data that had previously existed primarily as stored footage could eventually support performance analytics and training insights.

My work was focused on the cloud and infrastructure side of that problem rather than developing the underlying football-analysis AI models. The important architectural objective was to ensure that the data was accessible within an environment capable of supporting those future workloads.

Migrating large media datasets

Large video datasets introduce challenges that are very different from migrating ordinary application data. The migration strategy had to account for factors such as:

• total dataset size
• network bandwidth
• transfer duration
• source storage limitations
• destination storage organization
• integrity of transferred files
• avoiding unnecessary downtime
• future access patterns
• long-term storage costs

Rather than treating the video archive as a collection of ordinary files, it needed to be thought of as a large-scale data asset. Once migrated into cloud object storage, data could be organized and managed independently from the systems responsible for analyzing it, which allowed the storage layer to scale separately from the application's compute layer.

Scalability as an architectural requirement

One of the most important concepts I learned at TecCentric was that scalability should be designed into infrastructure rather than added only after an application begins failing under load. For the client applications I worked with, we considered questions such as:

• What happens if traffic doubles?
• What happens if an instance crashes?
• Can another instance take over?
• How quickly can capacity increase?
• Does the database or storage layer become the next bottleneck?
• Are applications stateful or stateless?
• Can workloads be distributed across multiple instances?
• How much infrastructure should remain active during low traffic?

This shifted my thinking from “Does the application run?” to “How does the application behave when demand changes?” That difference is fundamental when designing production cloud infrastructure.

Cost-efficient infrastructure

Cloud migration was also about avoiding unnecessary infrastructure spending. Traditional data centers often require organizations to purchase enough hardware to support their maximum expected workload, and that capacity may sit mostly unused outside peak periods. Cloud environments allow capacity to be more elastic.

By combining technologies such as:

• autoscaling
• managed application platforms
• container orchestration
• scalable object storage
• configurable compute resources

we could design environments where clients consumed infrastructure more closely aligned with their actual workload. This helped improve the balance between performance, availability and infrastructure cost, rather than optimizing one at the expense of the others.

Migrating more than ten client environments

Across the internship, I contributed to cloud migration work involving more than ten client environments. Each migration reinforced that cloud architecture cannot be approached as a copy-and-paste process. Different clients had different:

• legacy systems
• application architectures
• traffic patterns
• storage requirements
• security requirements
• network dependencies
• modernization goals

Some environments required a hybrid architecture. Some applications were good candidates for Kubernetes. Some workloads remained better suited to virtual machines. Others could use highly managed services such as App Engine. This taught me to approach cloud architecture by first understanding the workload and then selecting the appropriate service.

Deployment and scaling of client web applications

I also contributed to deploying and scaling more than ten client web applications on Google Cloud. Depending on the application's architecture, this involved combinations of GKE, GCE, App Engine, cloud networking, load balancing and autoscaling. The goal was to make applications resilient under concurrent load rather than depending on a fixed single-server architecture.

For scalable environments, I learned to think about the entire request path:

Improving scalability therefore required understanding more than the application itself. Every layer of the request path could potentially become a bottleneck.

Cloud architecture and infrastructure thinking

The biggest skill I developed at TecCentric was learning to think about software from an infrastructure perspective. As a developer, it is easy to focus primarily on application code. Cloud engineering required asking a different set of questions:

• Where does the application run?
• How does traffic reach it?
• How is it isolated from other workloads?
• What happens when demand increases?
• What happens when an instance fails?
• Where does persistent data live?
• How does an on-premise service communicate with a cloud workload?
• What should remain private, and what should be internet-facing?
• How should infrastructure scale?
• How do we avoid paying for resources that are not being used?

That experience gave me an early understanding of the infrastructure underlying modern production applications.

Technologies and concepts

What I took away from the role

My internship at TecCentric was my first opportunity to understand what happens below the application layer. Instead of only thinking about source code, I started thinking about the infrastructure responsible for actually running that code.

I learned that moving an application into the cloud is not simply equivalent to moving a server. A good migration can fundamentally change the architecture of the system. A fixed server can become an autoscaled containerized workload. A local storage system can become scalable object storage. A single application instance can become a highly available service distributed across several instances. An isolated data center can become part of a hybrid network connected to cloud infrastructure. And data that previously existed only for archival purposes can become accessible to analytics and AI workloads.

Working with clients such as the Qatar Football Association made that especially clear. The value of the cloud was not simply that their data could exist somewhere else. The value was that once the data and applications were moved into an elastic computing environment, the organization gained entirely new possibilities for how that information could eventually be processed and used.

That internship gave me a strong foundation in cloud computing and infrastructure architecture that I later carried into backend development, distributed systems, containerization, and AWS-based production environments.