6 Main Things to Consider Before Migrating to Cloud
Cloud computing, popularly referred to as ‘cloud,’ simply refers to the simple storage and access of data via the internet as opposed to the traditional storage that only utilized the computer hard drive. Over the internet, countless data centers together form what is unanimously referred to as the cloud.

Cloud computing is the basis of data science, a very significant pinnacle of the growth of organizations in today’s economy. Cloud is benefitting business with barely any IT infrastructure in place. The existence of cloud computing has led to the creation of so many cloud-based solutions such as Microsoft Azure and Office 365, which have helped businesses improve their productivity.

Cloud-based solutions for businesses help in enhancing accessibility, flexibility, and cybersecurity in a cost-effective manner. Instead of spending loads of money buying needless machines, contact organizations such as Alpacked.io for cloud consulting and take a step into cloud transforming your organization.

What is Cloud Migration?
The term cloud computing is not so alien to most people. As more people get acquainted with technology, they have slowly turned to more advanced solutions to their different activities. Business operations have benefited massively by the wonders of cloud computing and cloud-based solutions. Turning to the cloud for business solutions has been tested and proven by almost every facet of the business world. This evidenced success has triggered the need for existing and founding businesses to base their solutions to cloud-based solutions. As a result, more and more businesses are migrating to the cloud to answer some of the most intricate business matters.

This processing of moving operations to, from, or across the cloud is referred to as cloud migration. Cloud migration involves the transference of applications, databases, and IT processes into the cloud, from the cloud, or from one cloud to another. However, despite it being referred to as a move, the actual migration does not involve the physical hauling pieces of equipment from one data center to another.

The actual transfer, however, is not as simple as it sounds as it requires extensive planning. There are several types of cloud migrations that an organization can carry out. The first one is the movement of data from a local, on-premise data center to the public cloud. This migration could also be the movement of applications and data from one cloud provider or platform to another. This is the movement across the cloud, referred to as cloud-to-cloud transference. The third mode of migration is where an organization exits the cloud. This can also be referred to as cloud repatriation or reverse cloud migration. This is basically the opposite of the first type of migration. In this mode of migration, the applications, the data, and the IT operations are transferred from the cloud back to the local center.

Why do Businesses need to Migrate to Cloud?
Cloud computing is all about access to data. Amazon and Microsoft and some of the leading companies in the arena of cloud computing and delivery of cloud services. Without the cloud, businesses would have to buy, run, and maintain very sophisticated machines. The cost of such, not to forget the amount of skilled labor it demanded, was shocking. This was going to be a massive challenge for small and medium businesses to store, manage, and cost-effectively access their data. With cloud computing, this cost has been cut down and in its place access to raw and massive data that can be cost-effectively stored and retrieved at any time.

The data is easy to group as well. This is because businesses can now have all the teams from sales, accounts, marketing, and customer services gathering their related data into the saver reservoir that can be retrieved in an organized manner. This allows the different segments of the business’s stakeholders to access the same data in a coordinated and less cumbersome way. Cloud computing has contributed to this so much that one does not have to be on-site to access the information they need. Cloud computing in today’s business world is no longer a luxury but pretty much a necessity for competition and success. Below are some of the significant reasons for businesses to migrate to the cloud.

Scalability
Just as cloud computing is useful to small and medium businesses, it is equally applicable to large organizations. This adjustment to the size of data being handled is easy and less costly.

Cost
As soon as a company migrates to the cloud, their IT operations’ budget reduces since they no longer have to provide the storage machines, maintain them, or even upgrade them. This surplus cash can be channeled into other business needs.

Performance
Moving to the cloud will help the business perform better and even improve your customer experience. As a result of reduced travel of data, the business websites are going to experience lowered latency.

Flexibility
This is the benefit of allowing all business stakeholders to access data from anywhere. As a result, businesses have a bigger chance of growing and increasing the flexibility of their employees.

Cloud Migration Remains an Unfinished Task for Many Federal Agencies

Cloud migration has been a stated priority for federal agencies for over a decade, yet the COVID-19 pandemic exposed significant gaps in how far different agencies had actually progressed. While some agencies had modernized core infrastructure, many were still heavily dependent on legacy systems when operational disruptions hit hardest.

Third-party research compiled by Splunk suggests that cultural barriers among public sector leaders are a significant factor slowing cloud adoption. At the same time, the research indicates growing agency interest in FedRAMP-authorized cloud services as a path to accelerating digital modernization.

“Often we hear that leaders discuss modernization efforts, but a combination of legacy systems and poor insight into what they have, they are finding it difficult to actually start the modernization process.”

— Ashok Sankar, Director of Marketing and Strategy, Public Sector and Education, Splunk

The Scale of the Confidence Problem

One study cited by Splunk surveyed 156 IT decision-makers in the public sector. The results were striking: only 13 percent expressed confidence in their organization’s ability to modernize current systems and applications, including cloud and hybrid migrations. That leaves the overwhelming majority uncertain about their ability to execute one of the most fundamental IT transformations of the modern era.

This confidence gap has real consequences. Agencies that cannot accurately assess their current environment — what systems they run, how they interact, where sensitive data lives — will struggle to build a reliable migration plan regardless of how strong their intent is.

Key Challenges Organizations Face When Migrating to the Cloud

A separate study of more than 600 IT and security practitioners identified the most common obstacles to cloud migration. Three challenges stood out:

• Inability to achieve a strong security posture — cited by 65% of respondents
• Complexity of migrating from on-premises to cloud — cited by 61% of respondents
• Lack of visibility into resource utilization, metering, and monitoring — cited by 60% of respondents

Notably, all three of these challenges share a common root cause: insufficient data visibility. Organizations that cannot see what they have, how resources are being consumed, or where threats originate are unable to make confident, well-informed migration decisions.

Why Data Analytics and Security Analytics Are Central to Migration Success

Data analytics platforms address the visibility gap directly. By collecting and correlating data across heterogeneous sources — regardless of format or timescale — these tools provide IT teams with real-time views into system performance, availability, and security posture during and after migration.

“If you harness your data, you’ll be able to gather real-time insights to solve challenges like minimizing security risks and migrating to the cloud while at the same time improving citizen experience and mission assurance.”

— Ashok Sankar, Splunk

Practically, this means teams can:

• Monitor workload behavior before, during, and after lift-and-shift operations
• Detect anomalies or security events in real time as environments are reconfigured
• Correlate logs and metrics across on-premises and cloud environments in hybrid phases
• Build an accurate inventory of assets to inform migration sequencing and risk assessment

FedRAMP: The Federal Standard for Cloud Security Authorization

For U.S. federal agencies, cloud service selection is governed by the Federal Risk and Authorization Management Program (FedRAMP). FedRAMP provides a standardized security assessment framework so that agencies can adopt cloud services with confidence that they meet legally mandated federal security requirements.

“FedRAMP is the gold standard. It is an extensive evaluation process to ensure the highest level of cloud security to ensure a service is meeting legally mandated federal security measures. It saves the government 30-to-40% of their authorization costs.”

— Ashok Sankar, Splunk

The cost-savings claim reflects FedRAMP’s “do once, use many times” model: a cloud service provider (CSP) that earns a FedRAMP authorization can be reused by multiple agencies without each agency needing to independently assess the same controls from scratch.

Agency Adoption of FedRAMP Is Growing

Research compiled by Splunk references a U.S. Government Accountability Office (GAO) study that tracked FedRAMP adoption trends across federal agencies. Key findings from that study include:

• From June 2017 to July 2019, the number of instances of agencies using FedRAMP authorizations grew from 390 to 926 — more than doubling in two years.
• 21 of 24 agencies reported that FedRAMP made their data in cloud environments more secure or approximately as secure as their prior arrangements.
• 21 of 24 agencies reported that FedRAMP authorization reduced costs associated with reviewing Cloud Service Provider (CSP) assessment and authorization packages.

These figures indicate that FedRAMP is delivering measurable value — both in security outcomes and in operational efficiency — for the agencies that have adopted it.

What This Means for Agency Leaders Planning Modernization

The core message from the research is actionable: the tools needed to migrate successfully already exist and are accessible. The barrier for many agencies is not capability — it is awareness and the will to start. Sankar’s recommendation is straightforward: let data drive the modernization strategy.

“What leaders need to know is that the tools exist and are attainable that can give them the visibility they need to migrate systems properly while ensuring an acceptable risk posture and be confident that they can save time and money for their agency.”

— Ashok Sankar, Splunk

Practically, this means prioritizing platforms that offer:

• Broad data ingestion — the ability to collect logs, metrics, and events from legacy on-premises systems as well as cloud-native services
• Security analytics — correlation and alerting capabilities that surface threats in hybrid and multi-cloud environments
• FedRAMP authorization — so the platform itself meets federal compliance requirements without additional per-agency review cycles
• Real-time operational visibility — dashboards and monitoring tools that help teams understand resource utilization, application performance, and migration progress as it happens

Summary

Cloud migration for federal agencies is not simply a technical problem — it is a visibility and confidence problem. Research indicates that most public sector IT leaders lack confidence in their modernization capabilities, and the primary barriers they cite (security posture, migration complexity, and monitoring gaps) are all addressable through data analytics platforms. FedRAMP-authorized services provide an established framework for adopting these platforms securely, with a demonstrated track record of cost reduction and security improvement across participating agencies. For agencies still in the planning phase, the starting point is the same: gather data about what you have, and let that data guide where you go.

What Is Open Policy Agent?

Open Policy Agent (OPA) is a general-purpose, open-source policy engine maintained by the Cloud Native Computing Foundation (CNCF). It decouples policy decisions from application and platform code, allowing teams to express, enforce, and audit rules in a single, consistent way across microservices, CI/CD pipelines, API gateways, and — most relevantly for DevOps engineers — Kubernetes clusters.

Policies in OPA are written in Rego, a purpose-built declarative language that evaluates structured data (typically JSON) against a set of rules and returns a decision. That decision can be as simple as allow = true or as rich as a detailed object listing violations.

Why Kubernetes Needs Policy Enforcement

Kubernetes RBAC controls who can perform an action, but it does not control what configuration is allowed. Without additional policy enforcement, a developer with permission to create a Deployment can:

• Run containers as root
• Pull images from untrusted registries
• Omit resource limits, starving other workloads
• Mount the host filesystem or expose the host network
• Skip required labels that your monitoring or cost-allocation tooling depends on

OPA fills this gap by acting as a Kubernetes Admission Controller: every resource creation or update request passes through OPA before it is persisted to etcd, and OPA can approve, reject, or mutate it.

How OPA Integrates with Kubernetes

The Admission Webhook Model

Kubernetes exposes two webhook admission controller types:

• ValidatingAdmissionWebhook — can approve or reject a request.
• MutatingAdmissionWebhook — can modify the request payload before it is persisted.

OPA (or its Kubernetes-native distribution, OPA Gatekeeper) registers itself as one or both of these webhooks. When the API server receives a request, it serializes the object into an AdmissionReview JSON payload and forwards it to OPA over HTTPS. OPA evaluates the payload against loaded policies and returns an AdmissionResponse indicating whether to allow or deny.

OPA Gatekeeper vs. Standalone OPA

Standalone OPA requires you to manage the webhook registration, sidecar deployment, and policy loading yourself. Policies are typically pushed to OPA via its REST API or bundled and served from a remote bundle server.

OPA Gatekeeper is a Kubernetes-native OPA distribution that introduces two Custom Resource Definitions (CRDs):

• ConstraintTemplate — defines a new CRD and embeds the Rego logic.
• Constraint — an instance of that CRD that specifies which resources and namespaces the policy applies to and what parameters it uses.

Gatekeeper also adds an audit controller that continuously evaluates already-existing resources against current policies and reports violations, closing the gap between admission time and drift detection.

Writing Policies in Rego

Rego is a logic-based query language. The key idea is that you write rules that define when something is true. For admission control, you typically define a violation rule that produces a message when a constraint is breached.

Example: Require Resource Limits

The following Rego snippet (suitable for a Gatekeeper ConstraintTemplate) denies any container in a Pod that does not declare CPU and memory limits:

package kubernetes.admission

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.resources.limits.cpu
  msg := sprintf("Container '%v' must specify a CPU limit", [container.name])
}

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("Container '%v' must specify a memory limit", [container.name])
}

Example: Restrict Image Registries

This rule denies Pods that reference images from registries not in an approved list:

package kubernetes.admission

approved_registries := {"registry.example.com", "gcr.io/my-project"}

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  image := container.image
  not any_approved(image)
  msg := sprintf("Image '%v' is not from an approved registry", [image])
}

any_approved(image) {
  registry := approved_registries[_]
  startswith(image, registry)
}

Deploying OPA Gatekeeper on Kubernetes

The fastest way to get Gatekeeper running is to apply the official release manifest. Always check the Gatekeeper GitHub repository for the current stable release and recommended installation method.

# Replace <version> with the current stable Gatekeeper release tag
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/<version>/deploy/gatekeeper.yaml

After installation, Gatekeeper runs in the gatekeeper-system namespace. You can verify it is healthy:

kubectl get pods -n gatekeeper-system

Creating a ConstraintTemplate and Constraint

Below is a minimal ConstraintTemplate that enforces required labels, followed by a Constraint that activates it on all namespaces:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Missing required labels: %v", [missing])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["team"]

Testing Policies Before Deployment

OPA ships with a built-in test framework. Write unit tests alongside your Rego files and run them with:

opa test ./policies/ -v

The OPA Playground (play.openpolicyagent.org) is also a useful browser-based environment for iterating on Rego logic without a cluster. Gatekeeper additionally provides a gator CLI tool for running Gatekeeper-specific constraint tests in CI pipelines before policies ever reach the cluster.

Audit Mode and Dry-Run Enforcement

Rolling out new policies directly to a production cluster is risky. Gatekeeper supports an enforcementAction field on each Constraint:

• deny — rejects non-compliant resources at admission time.
• warn — allows the request but returns a warning message to the user (Kubernetes 1.19+).
• dryrun — records violations in the constraint’s status field without blocking anything.

Start with dryrun to understand the blast radius of a new policy, then graduate to warn, and finally to deny once you have fixed or exempted all legitimate violators.

Best Practices

• Store policies as code — keep ConstraintTemplate and Constraint YAML files in version control alongside your application manifests.
• Gate policies in CI — use opa test and gator verify in pull-request pipelines so policy regressions are caught before merging.
• Use namespaced exemptions carefully — Gatekeeper allows excluding namespaces via the constraint’s match block; document every exemption.
• Monitor audit violations — scrape Gatekeeper’s Prometheus metrics and alert when the violation count for a deny-mode constraint is non-zero for existing resources.
• Limit webhook failure policy — set failurePolicy: Fail for security-critical policies and ensure Gatekeeper is highly available; use failurePolicy: Ignore only for non-critical advisory checks.
• Separate policy development from cluster administration — consider a dedicated policy-as-code repository with its own review and approval workflow.

Summary

Open Policy Agent and its Kubernetes-native distribution Gatekeeper provide a powerful, auditable, and GitOps-friendly way to enforce organizational standards across Kubernetes clusters. By expressing policies in Rego, storing them as code, and using Gatekeeper’s audit and enforcement modes progressively, platform engineering teams can prevent misconfiguration at admission time while maintaining full visibility into policy compliance across the fleet.

What Is the JEDI Contract?

The Joint Enterprise Defense Infrastructure (JEDI) contract is a single-award cloud computing agreement issued by the U.S. Department of Defense (DoD). Its purpose is to modernize the Pentagon’s IT infrastructure by migrating workloads to a single enterprise cloud provider capable of operating at all three classification levels — unclassified, secret, and top secret — including at the tactical edge in operational environments.

The DoD described the contract as addressing “critical and urgent unmet warfighter requirements for modern cloud infrastructure at all three classification levels delivered out to the tactical edge.”

Structured as an initial two-year ordering period with a potential 10-year ceiling, the contract carries a maximum value of $10 billion. The DoD noted a guaranteed minimum of $1 million, with anticipated spending of approximately $210 million during the initial period based on expected project adoption.

Microsoft vs. AWS: A Surprise Outcome

When the DoD announced in October 2019 that Microsoft had won the JEDI award, it caught much of the industry off guard. For the better part of two years, Amazon Web Services (AWS) had been widely regarded as the frontrunner, given its dominant position in the government cloud market and its existing high-side certifications, including work with the intelligence community.

Several factors had, however, complicated AWS’s path to the award in the months leading up to the decision:

• Inspector General investigation: The Pentagon’s inspector general launched an inquiry into potential misconduct in the contract evaluation process, raising procedural questions about how requirements had been defined.
• Political friction: A widely reported feud between President Donald Trump and Amazon CEO Jeff Bezos created speculation about whether political considerations might influence the outcome.
• Microsoft’s quiet preparation: While attention was focused elsewhere, Microsoft steadily built its government cloud credentials, including announced plans to construct new Azure Government Secret data centers designed to handle classified workloads.

Patrick Moorhead, president and principal analyst at Moor Insights and Strategy, told SDxCentral: “From the looks of it, the DoD process looked unstructured and was full of fits and starts … almost political.”

The contract award process had also survived legal challenge, clearing reviews by both the Government Accountability Office (GAO) and the U.S. Court of Federal Claims before the final announcement.

Google’s Decision to Step Back

Google had been considered a potential bidder but ultimately withdrew from the competition. The company cited concerns that a JEDI contract might conflict with its internal AI ethics principles. Google also acknowledged that portions of the contract’s requirements fell outside the scope of its existing government security certifications. Internal employee opposition at both Google and Microsoft over work on military contracts had become a visible industry issue during this period.

At Microsoft, a group of employees published an open letter protesting the company’s pursuit of the contract. Microsoft responded by offering those employees the option to transfer to roles not connected to the JEDI work.

What the Win Means for Microsoft

Moorhead characterized the JEDI award as a “big” win for Microsoft, particularly because the contract is heavily weighted toward infrastructure-as-a-service (IaaS) workloads — an area where Microsoft’s Azure had historically trailed AWS. Much of Microsoft’s cloud revenue at the time derived from software-as-a-service (SaaS) products such as Office 365 and Dynamics 365 rather than raw compute and storage infrastructure.

Beyond the direct contract value, Moorhead noted the potential halo effect: a high-profile DoD win could strengthen Microsoft’s credibility with other government agencies and in regulated industries where security and compliance requirements are stringent.

What the Loss Means for AWS

In purely financial terms, Moorhead argued the loss was manageable for AWS. At the time of the award, AWS was running at roughly $36 billion in annualized cloud revenue. The roughly $1 billion per year average value of the JEDI contract represented a small fraction of that run rate.

“Other than a very public loss, financially it means nothing,” Moorhead wrote to SDxCentral. The more significant risk, he suggested, was reputational — the possibility that other government agencies or enterprise customers might reconsider AWS as a default choice and evaluate alternatives more seriously. Moorhead maintained that AWS remained larger in IaaS than its next ten competitors combined, a position of strength that one contract loss would not quickly erode.

Cloud Market Context

At the time of the JEDI award, both AWS and Microsoft had just reported quarterly financial results that came in below some analyst expectations for their respective cloud businesses. Despite that, market research firm Synergy Research Group projected that both vendors would increase their market share following the quarter. Chief analyst John Dinsdale forecast Amazon moving to approximately 33.5% of the global cloud infrastructure market and Microsoft to approximately 16.5%.

The JEDI decision illustrated how government procurement had become a meaningful competitive battleground for hyperscale cloud providers — not just for the contract revenue itself, but for the technical capabilities, certifications, and credibility that pursuing large government deals requires vendors to develop.

What Happened Next

AWS subsequently filed a legal challenge disputing the award, alleging that political interference had improperly influenced the evaluation. The resulting litigation placed the JEDI contract under court injunction, delaying implementation. The DoD eventually cancelled the JEDI contract in 2021 and launched a replacement multi-vendor procurement called the Joint Warfighter Cloud Capability (JWCC), awarding contracts to both Microsoft and AWS along with other providers. Readers should refer to current sources for the latest status of U.S. Defense Department cloud procurement.

AWS organises the work of achieving reliability into three areas: understanding your availability needs, designing applications for availability, and operational considerations. This article walks through each area in detail.

1. Understanding Availability Requirements

Not every application needs the same level of availability, and accurately gauging your requirements is the essential first step. Getting this wrong in either direction is costly: over-engineering availability drives up development and operational costs, while under-engineering it risks unacceptable downtime.

To illustrate the range, consider two-nines availability (99%) versus five-nines (99.999%). Two-nines permits roughly three and a half days of downtime per year—acceptable for a batch ETL job or internal reporting tool. Five-nines permits only around five minutes of downtime annually—a threshold appropriate for critical financial or transaction processing systems.

In practice, most applications are not monolithic: they are composed of multiple components with different availability requirements. An e-commerce platform, for example, might demand very high availability for its customer-facing order submission flow, while its fulfilment and reporting components can tolerate longer recovery windows. AWS recommends evaluating each component individually and setting differentiated availability targets accordingly.

Data Plane vs. Control Plane

AWS distinguishes between two planes of operation, each with different availability characteristics:

• Data plane: Handles real-time service delivery. Examples include DynamoDB read/write operations, RDS connectivity, and EC2 instance-to-instance communication. These paths must be highly available.
• Control plane: Handles configuration and provisioning activity. Examples include launching EC2 instances, creating S3 buckets, and provisioning RDS databases. These operations are less latency-sensitive and can tolerate brief interruptions.

By understanding this separation, teams can prioritise their resilience investment where it matters most—on the data plane paths that directly affect end users.

2. Application Design for Availability

Once availability requirements are defined, architectural patterns must be applied to meet them. AWS identifies five key practices:

2.1 Fault Isolation Zones

AWS provides multiple levels of physical and logical isolation to contain the blast radius of failures:

• Availability Zones (AZs): Multiple, physically separated data centres within a single AWS Region. Deploying across AZs delivers resilience with low inter-AZ latency—the right choice for most production workloads.
• Regions: Geographically separate AWS deployments offering maximum isolation. Appropriate for disaster recovery or data sovereignty requirements, but the higher latency makes them unsuitable for synchronous replication in latency-sensitive applications.

2.2 Redundant Components

Physical infrastructure must be designed without single points of failure. Redundant components—deployed across multiple AZs and, where appropriate, across multiple compute nodes and storage volumes—operate in parallel to absorb individual failures without degrading the overall service. The goal is that the failure of any single component is handled gracefully and transparently.

2.3 Microservice Architecture

Decomposing an application into microservices allows teams to apply appropriate availability targets and resilience patterns to each service independently. AWS identifies three core organisational and technical benefits of microservices:

• A small, focused team owns a single business capability, enabling cleaner organisational scaling.
• Each service can be deployed independently, as long as its API contract and other interface requirements are met.
• Each team can choose the technology stack best suited to their service’s requirements.

The trade-off is increased operational complexity and harder distributed debugging. AWS recommends each microservice explicitly publish its availability target, and suggests using AWS X-Ray for distributed tracing and debugging across service boundaries.

2.4 Recovery-Oriented Computing (ROC)

Recovery-Oriented Computing is a systematic design philosophy that prioritises rapid, automated recovery over attempting to prevent all failures. ROC encompasses:

• Isolation and redundancy to contain failure scope
• System-wide rollback capability
• Comprehensive monitoring and automated health checks
• Diagnostics tooling and modular design
• The ability to restart individual components cleanly

A key ROC principle is avoiding rarely-tested recovery paths. Every recovery mechanism should be exercised regularly in production or in realistic simulation environments so it is proven to work when genuinely needed.

2.5 Distributed Systems Best Practices

Distributed systems introduce a class of failure modes—network partitions, partial failures, retry storms—that require deliberate design patterns. AWS recommends the following techniques:

• Throttling: Once you understand each microservice’s request-handling capacity, implement throttling to keep services responsive under high load. Rather than crashing, a throttled service returns a rate-limit response or fails over to a redundant component. AWS API Gateway has built-in throttling support.
• Retry with exponential backoff: When retrying failed requests, introduce progressively longer pauses between attempts. This prevents retry storms from overwhelming an already-stressed dependency.
• Fail fast: Rather than queuing up requests indefinitely during a disruption—which delays recovery and exhausts resources—return errors immediately when a dependency is known to be unavailable.
• Idempotency tokens: Because retries are common in distributed systems, API requests should carry idempotency tokens. This allows the receiving service to detect duplicate requests and return an identical response without re-executing side effects (such as double-charging a payment).
• Constant work: Systems that experience dramatic swings between idle and peak load are harder to keep stable. Using filler or background work to keep compute resources uniformly occupied improves predictability and resilience.
• Circuit breaker: Avoid hard dependencies that can take down the entire system. A circuit breaker monitors calls to a downstream dependency and, when failures exceed a threshold, stops sending requests to it. The circuit can then fall back to cached data or degrade gracefully until the dependency recovers.
• Bi-modal behaviour and static stability: Components that behave differently under failure than under normal conditions create unpredictable cascading failures. Design components to operate in a degraded-but-stable mode in isolation, so that a partial outage does not propagate through the entire system.

3. Operational Considerations for Availability

Architectural patterns alone are not sufficient. Operational practices must reinforce them.

3.1 Automate Deployments

Manual deployments are a leading cause of reliability incidents. Automation reduces human error and enables safer, faster rollouts. Two deployment strategies are particularly relevant:

• Canary deployment: Route a small percentage of traffic to the new version first. Monitor error rates and key metrics, and only promote the release to full traffic once confidence is established.
• Blue-green deployment: Maintain two full production environments. Route production traffic to the blue environment while deploying and validating the new version in green. Shift traffic to green when ready; roll back instantly by switching back to blue.

Both strategies should be implemented through fully automated continuous integration and continuous delivery (CI/CD) pipelines. Changes should never be applied manually to production systems.

3.2 Testing

Understanding your true availability requires testing under realistic conditions. A well-rounded testing strategy should include:

• Unit and integration tests to verify correctness of individual components and their interactions
• Load and performance tests to verify behaviour under expected and peak traffic volumes
• Failure simulations (chaos engineering) to validate that recovery mechanisms work as designed in practice

3.3 Monitoring and Alarming

You cannot improve what you cannot measure. AWS outlines a layered monitoring approach:

• Instrument every application layer to emit metrics, logs, and traces for key components.
• Aggregate and store observability data using Amazon CloudWatch and Amazon S3.
• Configure CloudWatch alarms to trigger automated responses or page on-call engineers when thresholds are breached.
• Perform deeper analytics with services such as Amazon Athena, Amazon Redshift Spectrum, and Amazon QuickSight.

3.4 Operational Readiness Reviews (ORRs)

Before launching a new service or making a significant change to an existing one, AWS recommends conducting an Operational Readiness Review. An ORR validates that the system meets its defined operational requirements—covering monitoring, alerting, runbooks, capacity planning, and on-call processes. Learnings from incidents should feed back into the ORR checklist, and the review should be repeated at least annually as systems evolve.

3.5 Regular Auditing

Monitoring and alarming systems themselves can drift, become stale, or accumulate coverage gaps over time. Regularly audit your observability tooling to confirm that dashboards reflect current architecture, alarms cover critical paths, and runbooks are up to date.

Conclusion

Building for reliability on AWS is not about eliminating failure—it is about designing systems that expect failure and recover gracefully. By systematically applying the practices of the AWS Well-Architected Framework’s Reliability Pillar—from setting differentiated availability targets and leveraging fault isolation zones, to implementing circuit breakers, automated deployments, and rigorous operational reviews—engineering teams can build applications that remain available and trustworthy even under adverse conditions.

These are not theoretical guidelines: they represent patterns distilled from the operational experience of running large-scale distributed systems. Applying them consistently, and re-evaluating them as your architecture evolves, is the most dependable path to production reliability on AWS.

Why Legacy Migration Is a Pressing Problem

Modern organizations grow in two broad ways: organically, by building internal capabilities over time, or through acquisition, by absorbing companies that already have what they need. Both paths leave behind the same artifact—legacy infrastructure that was never designed for today’s cloud-native world.

For organically grown businesses, years of incremental decisions accumulate into a tightly coupled, difficult-to-change stack. For companies that grow through acquisition, the problem compounds: each acquired company arrives with its own tooling, platforms, and operational practices. The result is a heterogeneous environment that is expensive to run, difficult to automate, and slow to evolve.

Cloud adoption promises real relief. Moving workloads to cloud infrastructure can significantly reduce IT overhead costs and gives teams the elasticity to scale resources up or down on demand. Cloud environments also lend themselves well to automation, freeing engineering time that would otherwise be spent on manual operations.

Greenfield vs. Brownfield: The Reality Most Teams Face

In an ideal world, every team would start with a greenfield: a blank slate on which to design the optimal infrastructure from scratch. In practice, most engineering organizations operate in a brownfield—an environment layered with old systems, accumulated technical debt, and operational habits that resist change.

A brownfield environment is not inherently bad. Legacy systems often still deliver meaningful business value; that is precisely why they have not been decommissioned. The challenge is integrating them with modern cloud capabilities without breaking what already works, or writing off the investment those systems represent.

Hybrid cloud—a model that spans on-premises or legacy infrastructure alongside public or private cloud resources—has emerged as the practical answer for most enterprises. It allows organizations to modernize incrementally rather than all at once, which reduces risk and preserves continuity.

The Core Technical Challenge: Infrastructure Fragmentation

Even after you commit to a cloud strategy, fragmentation remains a serious obstacle. The major cloud providers each offer their own proprietary services and managed platforms. Teams that distribute workloads across providers quickly discover that each environment operates differently, making it hard to build consistent deployment pipelines, monitoring setups, or operational runbooks.

The result is what some engineers call “islands of infrastructure”—clusters of compute and storage that are built, deployed, and operated in incompatible ways. A DevOps team cannot maintain a truly consistent software delivery practice if the underlying platform changes significantly from one environment to the next.

Normalization: A Strategy for Consistency Across Environments

One of the most effective responses to infrastructure fragmentation is normalization—deliberately choosing tools and abstractions that behave consistently regardless of the underlying provider or hardware.

Open source technologies are well-suited to this role because they are not tied to any single vendor and can be deployed across a wide range of infrastructure targets. A normalized stack might look like this:

• Kubernetes for container orchestration, providing a consistent API for deploying and managing containerized workloads whether you are on AWS, GCP, Azure, or on-premises hardware.
• OpenStack for managing virtual machines in private cloud or data center environments, giving teams a familiar control plane that works independently of hyperscaler APIs.
• Serverless frameworks (such as Fission or OpenFaaS) for function-based workloads, abstracting away the underlying compute so that functions can run on any compliant platform.

The goal of this kind of normalized stack is not to eliminate all complexity—that is impossible. Instead, it is to contain complexity. Proprietary or environment-specific concerns get isolated to defined boundaries, while the majority of your application code and operational tooling can remain platform-agnostic.

Migration Approaches: Choosing the Right Strategy

There is no single right way to move a legacy system to the cloud. The appropriate approach depends on the system’s complexity, business criticality, and how much architectural change is acceptable. Common strategies include:

• Rehosting (lift and shift): Moving workloads to cloud VMs with minimal or no code changes. Fast and low-risk in the short term, but does not take advantage of cloud-native features and may carry the same operational overhead into the new environment.
• Replatforming: Making targeted changes—such as migrating from a self-managed database to a managed cloud database service—without rewriting the application. A middle path that captures some cloud benefits without full re-architecture.
• Refactoring (re-architecting): Fundamentally redesigning the application for cloud-native patterns, such as breaking a monolith into microservices. Delivers the greatest long-term benefits but requires the most time, skill, and risk tolerance.
• Retaining: Deliberately keeping certain systems on-premises because migrating them is not cost-effective or technically feasible at this time. A valid choice, and often part of a hybrid cloud strategy.
• Retiring: Decommissioning systems that no longer serve a business purpose. Often uncovered during migration planning and represents real cost savings.

For many organizations, the most pragmatic path is a combination: lift-and-shift in the short term to get off aging hardware, followed by incremental refactoring as time and budget allow.

Embrace Change as an Organizational Capability

Technical strategy alone is not enough. One of the consistent lessons from DevOps practice is that tooling changes succeed or fail based on whether the organization has also changed how it thinks about work.

The infrastructure ecosystem has evolved dramatically over the past fifteen years. Configuration management tools like Puppet and Chef established the idea that infrastructure should be defined as code. OpenStack brought open source principles to private cloud. Vagrant and later Docker made reproducible development environments mainstream. Kubernetes moved container orchestration from a niche concern to an industry standard.

Each of these shifts required teams to retire familiar practices and invest in new ones. Organizations that built a habit of adaptation moved through these transitions faster and with less disruption. Those that resisted found themselves repeatedly catching up rather than keeping pace.

For legacy migration specifically, this means building internal processes that support ongoing change: structured learning time, blameless retrospectives, cross-functional migration working groups, and executive support for the inevitable period of reduced velocity during transition.

Containing Complexity Rather Than Eliminating It

A useful mental model for legacy migration is that complexity cannot be destroyed—it can only be moved or reorganized. Every system that has run in production for years has accumulated essential complexity: edge cases that the code handles, operational knowledge that lives in runbooks, integrations with other systems that depend on specific behaviors.

The goal of a migration is not to produce a magically simple system. It is to move complexity from places where it is hard to manage—tangled codebases, undocumented server configurations, manual deployment processes—into places where it is easier to reason about and operate, such as well-defined service boundaries, infrastructure-as-code repositories, and automated pipelines.

Normalization supports this by providing consistent abstractions. When your containerized workloads all run through Kubernetes regardless of cloud provider, the operational complexity of multi-cloud management is largely contained at the cluster configuration layer rather than scattered throughout your application code and deployment scripts.

Practical Recommendations for Teams Starting a Legacy Migration

1. Inventory before you migrate. Understand what you actually have. Document dependencies, data flows, integration points, and SLAs. Many migrations stall because teams discover mid-flight that a system has more connections than anyone realized.
2. Prioritize by risk and value. Not every system needs to move at the same time or in the same way. Identify which systems are expensive to run on-premises, which are under active development, and which are stable but business-critical. Use that analysis to sequence your migration.
3. Standardize your toolchain early. Decide on your container runtime, orchestration platform, CI/CD pipeline, and observability stack before you begin migrating workloads. Retrofitting these after the fact is significantly harder.
4. Use infrastructure as code from day one. Whether you use Terraform, Pulumi, Ansible, or another tool, define your cloud infrastructure in version-controlled code. This makes environments reproducible and makes changes reviewable.
5. Plan for the hybrid period. Most migrations take longer than initially projected. Design your architecture so that legacy systems and cloud-native systems can communicate reliably during the transition, not just after it is complete.
6. Measure operational outcomes. Define what success looks like before you start: deployment frequency, change failure rate, mean time to recovery, infrastructure cost. Track these throughout the migration so you can demonstrate progress and catch regressions early.

Summary

Migrating legacy systems to the cloud is one of the most consequential and difficult infrastructure challenges an engineering organization can face. There is no silver bullet, and the right approach varies by organization, system, and business context. However, a few principles hold broadly: invest in normalization through open source, provider-agnostic tooling; choose your migration strategy based on the specific needs of each system; build organizational practices that support ongoing change; and treat complexity as something to be contained rather than eliminated.

A hybrid cloud model that combines the best of legacy investment with cloud-native capabilities gives most organizations the most realistic path to a modernized, cost-effective, and operationally sustainable infrastructure.

Overview

A survey of 450 C-level and VP/director-level technology leaders in the United States, UK, and Canada — conducted by 451 Research on behalf of cloud service provider Skytap — reveals a significant shift in how enterprises think about cloud migration. The era of straightforward lift-and-shift is fading. In its place, organizations are increasingly planning to refactor, modernize, or replace legacy applications to take advantage of cloud-native technologies. DevOps practices and skills are emerging as a critical enabler of that transition.

Lift-and-Shift Is Losing Ground

Historically, many organizations approached cloud migration by simply moving existing workloads to a cloud host with minimal or no code changes — the so-called “lift-and-shift” approach. The survey data suggests this strategy is declining in favor of more deliberate modernization:

• 28% plan to refactor applications using a mix of cloud-native and traditional technologies.
• 20% plan to adopt a Platform-as-a-Service (PaaS) environment.
• 20% plan a pure lift-and-shift with no changes to the underlying code.
• 20% will replace existing applications with Software-as-a-Service (SaaS) alternatives.

Jay Lyman, an industry analyst at 451 Research, cautioned that organizations still relying on lift-and-shift may be engaged in “wishful thinking.” In his assessment, most applications migrating to the cloud will require rework to some degree before they can run reliably and cost-effectively in a cloud environment.

Migration Timelines and Scope

The survey paints a picture of ambitious but measured migration plans across the respondent organizations:

• 67% of respondents plan to migrate or modernize at least half of their on-premises applications within the next 12 to 24 months.
• 47% expect to migrate between 50% and 75% of their applications.
• Only 20% plan to move 75% or more of their applications to a cloud platform within the same timeframe.

These figures suggest that while cloud migration is clearly a high priority, full-scale cloud adoption remains a long-term undertaking for most organizations rather than something achievable in a single planning cycle.

DevOps and Agile Are the Dominant Migration Methodologies

When asked which methodologies they rely on to drive cloud migration projects, respondents pointed strongly to DevOps and agile practices:

• 54% said they are already relying on DevOps processes.
• 46% said they are relying on agile methodologies.

This confirms DevOps as more than a software delivery philosophy — it is now a core operational framework for managing complex, multi-phase cloud migrations. The iterative, automation-driven nature of DevOps practices aligns well with the incremental approach most organizations are taking to modernize their application portfolios.

Skills Shortages Are a Major Bottleneck

Talent acquisition and retention emerged as a critical concern. Respondents identified the following skill sets as highest priority:

• 55% — Cloud migration expertise
• 52% — Application modernization using cloud services
• 50% — DevOps skills (tied with multi-cloud operations expertise)

The strong demand for DevOps talent directly reflects how central these practices have become to successful cloud initiatives. Organizations that lack this capability are likely to face slower migration timelines and higher risk of failed modernization efforts.

Workload Placement and Multi-Cloud Realities

The survey also explored how organizations are making workload placement decisions:

• 37% said placement decisions are driven primarily by where the application will run best.
• 26% cited identifying the best-of-breed cloud-native service as the key driver.
• Only 19% said their organizations plan to use multiple public cloud providers in a coordinated way.

Jay Lyman noted that while hybrid and multi-cloud architectures represent the aspirational target for most IT organizations, the practical reality is that most will be running multiple clouds in isolation — rather than as a unified strategy — for many years to come. True hybrid cloud orchestration remains an advanced capability that few organizations have achieved at scale.

On-Premises Applications Still Dominate — And Many Are Mission-Critical

The sheer scale of on-premises application portfolios helps explain why migration is a long-term challenge:

• 80%+ of respondents reported managing more than 100 applications.
• 74% said at least half of those applications are still on-premises.
• 71% said more than half of their on-premises applications are mission-critical.

Migration complexity is further compounded by application type. Just over half of respondents said that core business applications — including CRM, ERP, and data analytics platforms — are the least suited for hyperscale cloud environments. These are precisely the applications that tend to be most deeply integrated with existing infrastructure, making refactoring expensive and time-consuming.

Security Remains the Top Cloud Challenge

Despite years of cloud adoption and maturing security tooling, security continues to be the most-cited challenge in cloud deployments. 56% of survey respondents identified security as the biggest obstacle to deploying applications in the cloud — a finding consistent with broader industry trends at the time of the survey.

Key Takeaways for DevOps and Platform Teams

• Lift-and-shift alone is not a viable long-term strategy. Plan for refactoring, even if initial migrations are phased.
• DevOps capabilities are directly linked to migration success. Teams without established DevOps pipelines and culture will struggle to modernize at the required pace.
• Skills investment is non-negotiable. Cloud migration expertise, application modernization skills, and DevOps proficiency are the top hiring priorities among leading organizations.
• Expect the migration to take years, not months. The volume of mission-critical on-premises applications and the complexity of modernization mean that cloud transformation is an extended program of work, not a single project.
• Multi-cloud strategy is aspirational for most. Focus on getting individual cloud environments right before attempting unified multi-cloud operations.

Survey conducted by 451 Research on behalf of Skytap in 2018, covering 450 C-level and VP/director-level technology leaders in the US, UK, and Canada. Original coverage via devops.com.

Why APM Matters in a Cloud-First World

IT organizations are no longer back-office cost centers—they are strategic drivers of business growth, customer engagement, and revenue generation. Cloud adoption has accelerated this shift by making infrastructure more elastic and cost-efficient, allowing teams to focus on delivering value rather than managing hardware. Alongside this transition, DevOps has emerged as the operating model best suited to cloud environments, tightly aligning software development and IT operations to improve delivery speed and reliability.

Many applications deployed in cloud environments are customer-facing, which means their performance has a direct impact on revenue and user satisfaction. Slow response times, errors, or outages do not just frustrate users—they erode trust and can have measurable business consequences. This is the context in which Application Performance Monitoring (APM) has become indispensable.

What Is Application Performance Monitoring (APM)?

APM refers to the practice of continuously monitoring the availability, performance, and behavior of software applications—typically in real time. APM tools collect metrics such as response times, error rates, transaction traces, infrastructure utilization, and end-user experience data. The goal is to give development and operations teams a clear, shared picture of how an application is behaving at any given moment, enabling rapid identification and resolution of performance issues.

In a cloud migration context, APM provides visibility into how applications behave across distributed, dynamic infrastructure—something that traditional on-premises monitoring tools were not designed to handle at scale.

Three Areas Where APM Drives Cloud Migration Success

APM supports a successful cloud migration and a healthy DevOps practice in three interconnected ways:

1. Supporting both sides of the DevOps model
2. Enabling continuous delivery at scale
3. Bridging cross-functional communication and collaboration

1. Supporting Each Side of DevOps

Development and operations teams have historically operated with competing priorities. Developers want to ship features and fixes quickly; operations teams prioritize stability and predictability. In a cloud environment, this tension can intensify: the cloud makes rapid development easier, but it also introduces new complexity around performance, cost, reliability, and scalability.

APM helps bridge this gap by giving both sides actionable, shared data:

• Operations teams can quickly pinpoint performance bottlenecks, identify root causes of slowdowns or failures, and triage issues before they escalate.
• Development teams receive detailed diagnostic information—error logs, code-level traces, performance SLA violations—that allows them to address issues at the source rather than guessing.
• Both teams can act proactively, using APM alerts and trend data to prevent issues from reaching end users in the first place.

This shared visibility fosters the mutual respect and collaboration that effective DevOps requires. Rather than pointing fingers when something breaks, both teams are looking at the same data and working toward the same goal.

2. Enabling Continuous Delivery

Continuous delivery (CD) is the practice of releasing application updates on a frequent, automated cadence so that new features reach users as quickly as possible. Cloud infrastructure is ideally suited to CD because it can scale dynamically to match the demands of any deployment phase—from a small staging environment to a massive production rollout.

However, the speed of continuous delivery also increases the risk of introducing performance regressions or bugs into production. APM supports a CD pipeline by:

• Providing real-time feedback during each deployment, so teams can immediately detect if a new release has degraded performance.
• Validating that application functions meet performance SLAs before and after each release—for example, confirming that a critical API endpoint still responds within an acceptable threshold.
• Reducing the blast radius of defects by enabling fast detection and rollback decisions before issues spread to all users.
• Keeping QA and testing processes in step with the pace of development, rather than becoming a bottleneck.

Without APM, continuous delivery in a cloud environment is essentially flying blind—teams may be deploying faster but have little confidence in what is actually happening in production.

3. Cross-Functional Communication and Collaboration

Cloud migrations involve multiple stakeholders: application owners, business analysts, developers, QA engineers, and operations teams. Each of these groups needs visibility into application performance, but they typically care about different dimensions of it. APM can serve as the connective tissue that gives each group the information they need in a form they can act on.

Here is how APM serves different stakeholders across the delivery lifecycle:

When all stakeholders are working from a shared, real-time view of application health, decisions are faster, escalations are rarer, and the organization as a whole becomes more capable of delivering a consistently high-quality user experience.

APM in Practice: From Development to Production

A well-implemented APM strategy spans the entire application lifecycle:

• During development: APM instruments code under test to surface performance regressions early. If a function is required to complete in under one second, APM makes this expectation testable and measurable—not just aspirational.
• Pre-production: Performance benchmarks are validated in staging environments that reflect production conditions. Only applications that meet defined performance thresholds are promoted.
• In production: APM continuously monitors live applications, generating alerts when performance degrades, automatically capturing diagnostic data, and enabling operations teams to triage problems with full context rather than starting from scratch.
• Post-incident: Historical APM data provides a record of what changed, when it changed, and how performance was affected—invaluable for post-mortems and future planning.

Key Takeaways

• Cloud migration increases the complexity and scale of application environments, making real-time performance visibility more important than ever.
• APM aligns development and operations teams by giving them a shared, data-driven view of application health.
• Continuous delivery pipelines require APM to maintain quality and speed simultaneously.
• APM data is useful not just for engineers but for business stakeholders who need to understand how application performance affects user engagement and revenue.
• Implementing APM before, during, and after a cloud migration significantly reduces the risk of performance issues going undetected until they affect users.

For organizations undertaking a cloud migration, APM is not an optional add-on—it is a foundational capability that enables every other part of the DevOps model to function effectively.

This article breaks down how to sequence and combine these disciplines based on whether your primary modernization driver is worker productivity or cost reduction — and how platform decisions around containers and cloud naturally follow from that foundation.

Why Modernization Projects Fail

Application modernization is widely agreed to be necessary, yet it has a poor track record. Common failure modes include:

• Technical tunnel vision: Teams optimize for a specific technology (e.g., containers) rather than a measurable business outcome.
• Scope creep and cost overruns: Without a clear goal, every new tool or practice becomes an attractive addition, inflating timelines and budgets.
• Disconnected architecture principles: Modernization efforts that don’t align with a target application architecture produce fragmented systems rather than cohesive improvements.

Successful modernization projects are anchored to one of two primary goals: improving worker productivity by delivering better IT support faster, or reducing IT operational costs and error rates. The roles of CI/CD, DevOps, containers, and cloud are then derived from that goal — not chosen in advance.

CI/CD as the Starting Point for Productivity-Driven Modernization

When the goal is improving how IT supports business workflows, continuous integration and continuous delivery (CI/CD) should lead the modernization effort. The core reason is straightforward: people are poor at predicting how useful a new capability will be until they can actually test it in operation. CI/CD shortens the feedback loop between development and operational experience, allowing architects to rapidly adapt applications to what users actually need.

Automating application updates through CI/CD also creates a natural on-ramp for evaluating the other key trends:

• It forces clarity about how components are built, tested, and deployed — essential groundwork for both containerization and DevOps.
• It reduces the time required to inject new capabilities into applications, directly improving IT’s ability to support business operations.
• It surfaces operational issues early, particularly around ensuring that changes to application components are correctly reflected in deployment and configuration management processes.

One important caveat: CI/CD changes development practices significantly enough that it may require application redesign. Teams should anticipate this and plan accordingly, rather than treating CI/CD as a purely tooling decision.

DevOps as the Starting Point for Cost-Driven Modernization

Cost-driven modernization has a troubled history. DevOps, containers, and public cloud all reduce IT operational costs, but few enterprises successfully evaluate all three in parallel. The more productive approach is to start with DevOps — specifically, deployment and redeployment automation — and let that work guide subsequent platform decisions.

Thinking in States and Events

Regardless of whether your chosen automation tool is declarative (e.g., Puppet) or prescriptive (e.g., Chef), the key to effective DevOps implementation is modeling your application in terms of operational states and application events:

• Operational states are discrete, well-defined conditions such as normal, heavy load, or impaired. Each state has an associated set of conditions: the relationships between application components, network connections, and hosting resources.
• Application events are signals that indicate a transition from one state to another, triggering corresponding DevOps automation actions.

A declarative tool defines the desired conditions for each state. A prescriptive tool defines the steps required to reach those conditions. Either approach works, but the conceptual model of states and events must come first.

DevOps Forces Application Componentization

A DevOps assessment will identify the actual elements that get deployed and redeployed. This almost always surfaces the question of application componentization — and this is where most modernization planners encounter a critical architectural decision.

It is possible to implement CI/CD without restructuring an application into components. It is not possible to plan effective DevOps without it. Componentization determines:

• What can be independently deployed, scaled, or replaced.
• How containers map to application functionality (containers are increasingly tied to component and microservices architectures).
• Which application elements can scale under load or be swapped out during a failure in a public cloud environment.

This is why DevOps serves as the natural lead-in to platform decisions around containers and cloud — it forces the architectural clarity that those platforms require.

Choosing Between Containers and Cloud: Let DevOps Decide

Once DevOps is in place and application componentization is understood, the right hosting and deployment model becomes much clearer. Several patterns are worth considering:

Split Hosting: Cloud Front End, Containers Back End

Applications with distinct front-end and back-end structures — where agility and resiliency are priorities — may benefit from a hybrid approach: public cloud services handling the user-facing front end, with containers running the back-end processing in the data center. This setup requires cloud management tooling that integrates both environments and is compatible with your DevOps decision-making and handoff processes. Container orchestration in the back end should maximize scalability under load, particularly at the integration point with the cloud front end.

Data Center First: Containers Without Cloud

If security, compliance, or data sovereignty requirements mandate that primary processing remain in the data center, containerization is the logical next modernization step — decoupled from any public cloud dependency. Containers still provide the componentization, portability, and operational consistency benefits without requiring workloads to leave the data center.

All Three Will Eventually Converge

Regardless of the sequence, most mature modernization programs will ultimately incorporate CI/CD, DevOps, containers, and some degree of cloud. These are not mutually exclusive choices — they are complementary layers of a modern application delivery platform. The goal is to sequence them in a way that delivers value at each step, rather than attempting a simultaneous adoption of all four that risks delivering none well.

A Practical Modernization Sequence

Based on the primary driver, a reasonable sequencing approach looks like this:

In both paths, the work done at each stage directly informs and enables the decisions that follow. Componentization is the linchpin: it unlocks the full value of DevOps, makes containers practical, and maximizes the cost and scalability benefits of public cloud.

Key Takeaways

• Define the business goal — productivity or cost — before selecting technologies.
• CI/CD is the best starting point when the goal is faster delivery of useful functionality to users.
• DevOps automation is the best starting point when the goal is reducing operational cost and error rates.
• Neither containers nor cloud can be optimally planned without first understanding how your application breaks into deployable components.
• Avoid tunnel vision: the end state for most organizations includes all of these disciplines working together.

For many enterprises, migrating to a cloud-delivered model for IT systems is a compelling proposition. Cost efficiency, elastic scaling, and improved business agility are all strong drivers pushing CIOs toward public cloud adoption. Most organizations are either already migrating or actively planning to do so. But the leap from on-premises infrastructure to cloud-hosted platforms is not without significant challenges — including regulatory compliance, data governance, billing complexity, and security risks.

Minimizing migration risk must be a top priority. Traditional security tools designed for perimeter-based, hardware-defined environments often do not translate cleanly to cloud environments. CIOs and CSOs need to address specific risk categories before migration begins — not after.

Key Risks to Address Before You Migrate

1. Regulatory Compliance

Depending on your industry, your organization may be subject to standards such as PCI DSS (payment card data), SOX (financial reporting), or HIPAA (protected health information). Moving to the cloud does not change the underlying compliance requirements — you are still responsible for meeting them — but it often requires different technical approaches to achieve them.

Key controls to implement in a cloud compliance program include:

• Identity and Access Management (IAM): Fine-grained, role-based access controls to limit who can touch what resources.
• Audit logging and anomaly detection: Comprehensive, tamper-evident logs and automated alerting for unusual behavior.
• Incident response and responsible disclosure: Documented runbooks for responding to breaches, including notification obligations under applicable regulations.

2. Data Governance

A well-formed data governance strategy is essential before any data moves to the cloud. This means defining clear data classification policies — knowing which data is sensitive, who is authorized to access it, and under what conditions it can be moved or shared.

Practical controls include:

• Data access policies: Users should not be able to access or move data without explicit authorization. Enforce least-privilege principles.
• Encryption in transit and at rest: Encrypt sensitive data at every stage. Under HIPAA, encryption of PHI at rest is effectively required. Elsewhere, it is best practice.
• Data residency and locality: Cloud providers operate globally. Understand where your data physically resides and whether that satisfies regulatory or contractual requirements for your jurisdiction.

3. Infrastructure and Application Security

One of the most significant architectural shifts in cloud security is the move away from hardware-defined, perimeter-based security models toward software-defined security. In the cloud, there is no true network perimeter — resources are elastic, programmable, and potentially accessible from anywhere.

This has two important implications:

• Continuous configuration monitoring: Because infrastructure can be provisioned and changed programmatically at any time, a misconfiguration can expose critical assets within minutes. Automated change monitoring tools (such as AWS Config, Azure Policy, or open-source alternatives like Cloud Custodian) help ensure configuration drift is caught immediately.
• Continuous application security testing: Security testing should be integrated into your CI/CD pipeline, not treated as a pre-launch gate. Each deployment should trigger relevant security scans — SAST, DAST, dependency checks — to provide ongoing security assurance rather than point-in-time snapshots.

The Three Primary Cloud Migration Approaches

Once your team has addressed the risk factors above, you can move to selecting a migration strategy. The right approach depends on your business objectives, timeline, budget, and the characteristics of the workloads being moved. There are three broad strategies most organizations use:

1. Lift and Shift (Rehosting)

Lift and shift involves mapping your existing on-premises hardware or virtual machines to equivalently sized cloud instances with minimal changes to the application itself. For example, if your application server runs on 4 vCPUs, 64 GB of RAM, and 512 GB of local storage, you select a cloud instance type that matches those specifications as closely as possible and move the workload over.

When it works well: Lift and shift is typically fastest to execute and is well-suited to getting out of a data center on a deadline, or as a first step before further optimization.

Key limitation: On-premises infrastructure is typically over-provisioned to handle peak loads because it lacks elastic auto-scaling. When you lift that workload into the cloud at the same static size, you often pay for that over-provisioning continuously — losing one of cloud’s primary cost advantages. This approach is best treated as temporary unless cost is not a concern.

2. Refactor and Re-architect

This approach treats migration as an opportunity to modernize applications so they can take full advantage of cloud-native features — particularly auto-scaling, managed services, and pay-per-use pricing. Rather than lifting existing application architecture intact, teams invest time in re-architecting services to be more performant, more maintainable, and more cost-efficient at cloud scale.

What this might involve:

• Breaking monolithic applications into independently scalable services.
• Replacing expensive commercial middleware or databases with open-source or cloud-native equivalents.
• Adopting managed services (object storage, managed databases, message queues) to reduce operational burden.
• Building for horizontal scaling rather than vertical scaling.

Trade-off: This approach requires more time and engineering investment upfront but typically yields the best long-term cost, performance, and reliability outcomes.

3. Shelve and Spend (Replace with SaaS)

The third strategy involves retiring an existing on-premises application entirely and replacing it with a SaaS offering. Rather than migrating the workload at all, you buy the capability as a service.

A common example is Human Capital Management (HCM) systems. Many organizations run legacy HCM platforms — often a collection of separate codebases joined together with a relational database — that are expensive to maintain and difficult to extend. Migrating to a purpose-built SaaS HCM platform modernizes the business logic, eliminates the infrastructure operational burden entirely, and shifts responsibility for uptime and security to the SaaS provider.

When to consider it: This approach is most appropriate for non-differentiating business functions where a mature SaaS market exists — HR, payroll, CRM, email, collaboration tools — and where the cost and complexity of running the service yourself exceeds the value of owning it.

Key consideration: SaaS adoption introduces its own vendor dependency, data portability, and integration risks. These should be evaluated carefully before committing, particularly for business-critical functions.

Choosing the Right Approach

In practice, most organizations use a combination of all three strategies across different workloads. A large enterprise migration might lift-and-shift legacy infrastructure to exit a data center lease, re-architect its customer-facing applications for scale and resilience, and simultaneously move internal tools like HR and email to SaaS platforms.

The key is to make deliberate choices based on workload characteristics and business goals — rather than defaulting to lift-and-shift for everything and inheriting its cost and technical debt consequences at cloud scale.

Addressing compliance, data governance, and security architecture before any of these migration strategies begin is what separates organizations that migrate successfully from those that create new problems in the cloud while solving old ones on-premises.

1. Vendor Lock-in, Switching Costs, and Complexity

Vendor lock-in is consistently cited as one of the top fears among enterprise IT decision-makers considering public cloud. The concern is rational: once an organization builds applications around a provider’s proprietary services — managed databases, serverless runtimes, AI APIs — extracting that workload later becomes expensive and technically complex.

Key questions that surface during cloud strategy reviews include:

• What happens if a provider dramatically raises prices after workloads are fully migrated?
• Can data and applications be moved to a competing provider quickly if service quality degrades?
• How much engineering effort is required to re-platform proprietary services?

For enterprises operating at petabyte scale, data egress costs and migration timelines alone can make switching providers prohibitive. Hybrid cloud reduces this risk by keeping a portion of critical workloads on infrastructure the organization controls, while using public cloud for elastic or commodity workloads where portability matters less.

Reducing lock-in risk has also driven interest in open standards, Kubernetes-based portability, and multi-cloud management planes — all of which are easier to implement in a hybrid model than in a single-vendor public cloud model.

2. Fear of Outages

No infrastructure is immune to failure — on-premises or cloud-hosted. However, the concentration of workloads in major public cloud regions means that a single provider incident can simultaneously affect thousands of businesses. High-profile outages at major cloud providers have demonstrated how quickly a regional failure can cascade across internet-facing applications.

It is worth keeping these expectations in context: a 99.9% uptime SLA still permits approximately 8.76 hours of downtime per year. For consumer-facing or revenue-critical applications, even a fraction of that downtime can cause significant financial and reputational damage.

Hybrid cloud allows organizations to architect for resilience by distributing workloads across private infrastructure and multiple cloud regions or providers. Critical systems can continue operating on private infrastructure while public cloud resources handle burst traffic — reducing the blast radius of any single failure.

3. Migration Challenges

Moving a live production system to public cloud is one of the most complex infrastructure projects an organization can undertake. The larger the dataset and the higher the transaction volume, the greater the risk. Teams must plan data migration sequencing, handle schema changes, manage dual-write periods, and validate data integrity — all while keeping the business running.

Large-scale migrations have been completed successfully. Evernote, for example, migrated approximately 3 petabytes of data to Google Cloud Platform over 70 days by starting small and incrementally accelerating once confidence in the process was established. That kind of deliberate, phased approach is repeatable, but it requires significant engineering resources and executive support.

Hybrid cloud is often the practical intermediate state during migration. Organizations can move workloads incrementally while keeping mission-critical systems on proven infrastructure, reducing the risk of a big-bang migration that fails at the worst possible moment.

4. Public Cloud Cost at Scale

Public cloud providers have consistently reduced list prices over time. Despite these reductions, the economics of public cloud do not automatically favor large-scale, steady-state workloads over on-premises infrastructure. Cloud pricing works extremely well for variable, elastic, or short-lived workloads. For always-on, predictable workloads running at scale, on-premises or colocation infrastructure can be more cost-effective on a per-unit basis.

This cost dynamic explains why many large financial institutions and enterprises have been cautious about full public cloud adoption. Hybrid cloud lets organizations put elastic or unpredictable workloads on public cloud — where the pay-as-you-go model is financially advantageous — while keeping high-utilization, predictable workloads on owned infrastructure where capital expenditure has already been amortized.

5. Existing Infrastructure and Sunk Investments

Organizations have made substantial capital investments in on-premises data centers — servers, networking, storage, software licenses, and facilities. Writing off that infrastructure overnight to move everything to public cloud is rarely justifiable to finance teams or boards, especially when the infrastructure still has years of useful life remaining.

Hybrid cloud provides a financially rational path: organizations can continue extracting value from existing investments while selectively adopting public cloud for new workloads, development and test environments, disaster recovery, and capacity overflow. As hardware reaches end-of-life, the balance can gradually shift toward cloud without requiring a disruptive write-off event.

6. Shortage of Cloud Skills

Cloud adoption requires specialized skills — cloud architecture, DevOps practices, infrastructure-as-code, cloud security, and cost optimization — that remain in short supply across the industry. Organizations that have built experienced on-premises infrastructure teams often find that retraining or hiring for cloud operations takes considerably longer than anticipated.

This talent gap is a meaningful adoption barrier. Hybrid cloud allows organizations to retain and leverage their existing infrastructure expertise while gradually building cloud skills, rather than forcing an abrupt transition that outpaces the team’s ability to operate the new environment safely.

7. Multi-Cloud Is Harder to Implement Than It Sounds

Multi-cloud — running workloads across two or more public cloud providers simultaneously — is widely discussed as the solution to vendor lock-in and outage risk. In practice, it introduces significant operational complexity. Each major cloud provider has its own networking model, IAM framework, storage APIs, and managed service interfaces. Building applications that are genuinely portable across providers requires deliberate architecture decisions from the ground up and ongoing operational discipline to maintain.

Finding engineers who can effectively develop and operate workloads across AWS, Azure, and GCP simultaneously is challenging. Multi-cloud also tends to increase total cloud spend because it often precludes committed-use discounts and requires duplicate tooling and observability infrastructure for each provider.

Hybrid cloud with a single primary public cloud provider is often a more achievable starting point. It delivers resilience and flexibility without the full operational overhead of a true multi-cloud architecture.

8. Compliance and Regulatory Requirements

Regulated industries — financial services, healthcare, government, and others — operate under strict rules about where data can be stored, how it must be encrypted, who can access it, and how long it must be retained. Data sovereignty requirements in many jurisdictions mandate that certain categories of data remain within national borders. GDPR, HIPAA, PCI-DSS, and sector-specific regulations impose additional controls that must be verifiably met.

Public cloud providers have expanded their compliance certifications and regional data center footprints significantly, making it possible to meet many of these requirements on public cloud. However, for some organizations in highly regulated sectors, the simplest and most auditable approach is to keep regulated data on private infrastructure they fully control while using public cloud for less-sensitive workloads. Hybrid cloud makes this separation architecturally explicit.

9. Security Concerns

Security remains one of the most frequently cited barriers to cloud adoption in enterprise surveys. This concern applies to both public cloud and on-premises environments — neither is inherently more secure than the other. Major cloud providers invest heavily in physical security, network security, and compliance tooling, often exceeding what individual enterprises can achieve in their own data centers.

Despite this, security anxiety persists — partly due to the shared responsibility model, which requires organizations to correctly configure cloud services themselves, and partly due to the visibility challenges that come with third-party infrastructure. Security misconfigurations in cloud environments remain a leading cause of data breaches.

Hybrid cloud allows security-sensitive workloads and data to remain on infrastructure where the organization has direct control and full visibility, while non-sensitive workloads benefit from public cloud scale and resilience.

10. Hybrid Cloud Delivers Meaningful Benefits With Manageable Risk

The most compelling argument for hybrid cloud is simply that it directly addresses the nine challenges listed above without requiring organizations to solve all of them simultaneously. Hybrid cloud does not eliminate vendor lock-in risk, but it reduces it. It does not eliminate outage risk, but it enables more resilient architectures. It does not erase compliance complexity, but it provides a clear separation between regulated and unregulated workloads.

For most enterprises today, hybrid cloud represents the optimal balance between operational continuity and cloud-driven innovation. It provides a path for organizations to modernize incrementally — preserving existing investments, developing cloud skills progressively, meeting regulatory requirements, and managing costs — while still capturing the scalability and developer productivity benefits that public cloud delivers.

As cloud providers continue expanding regional footprints, reducing prices, improving portability tooling, and deepening compliance certifications, some of the barriers driving hybrid adoption will diminish. Until those gaps close completely, hybrid cloud will remain the pragmatic choice for the majority of enterprises operating at scale.

Summary

• Vendor lock-in — Proprietary services and data egress costs make switching difficult and expensive.
• Outage risk — Regional cloud failures can affect many customers simultaneously; hybrid architectures limit blast radius.
• Migration complexity — Large-scale migrations require significant planning and carry execution risk.
• Cost at scale — Public cloud economics favor elastic workloads; steady-state workloads may be cheaper on owned infrastructure.
• Existing investments — Capital already spent on data center infrastructure is not easily written off.
• Skills shortage — Cloud expertise remains scarce; hybrid allows gradual skill development.
• Multi-cloud complexity — True multi-cloud is architecturally and operationally demanding.
• Compliance requirements — Regulated data may need to stay on controlled, auditable infrastructure.
• Security concerns — Shared responsibility and configuration risk keep security top of mind.
• Pragmatic balance — Hybrid cloud addresses the majority of adoption barriers without requiring organizations to solve all of them at once.

Before you commit to a cloud migration project, work through the five questions below. Each one surfaces a category of risk that can derail an otherwise well-intentioned effort.

1. How Much Downtime Should You Expect?

Every migration involves a cutover window—the moment you stop writes to the old environment and bring the new one live. Depending on the complexity of your workloads and the migration strategy you choose, that window can range from a few minutes to several days.

Common migration strategies carry very different downtime profiles:

• Lift-and-shift (rehost): Fastest to execute, but cutover downtime is usually higher because application-level replication is rarely in place.
• Re-platform: Moderate complexity; some components can be migrated and tested in parallel, reducing the cutover window.
• Refactor/re-architect: Longest runway, but a well-implemented blue-green or canary deployment can bring cutover downtime close to zero.

Quantify your acceptable recovery time objective (RTO) before choosing a strategy. If your business cannot tolerate more than 15 minutes of downtime, a simple lift-and-shift scheduled over a weekend may not be sufficient—you will need a parallel-run approach with traffic failover.

2. Is Your Software Up to Date?

Applications that run on aging operating systems or rely on hardware-level features (specific CPU flags, legacy drivers, dongle-based licensing) can become blockers the moment you attempt to migrate them to a virtualized or containerized cloud environment.

Before migration, audit every application against these criteria:

• Active vendor support: Is the software still receiving security patches? Cloud providers regularly retire older guest OS images, so unsupported software versions may be left behind.
• Licensing portability: Some perpetual licenses are tied to physical MAC addresses or on-premises servers. Moving to the cloud may require a license conversion or additional purchase.
• Architecture compatibility: 32-bit applications, COM/ActiveX components, and legacy database clients may not run cleanly on modern cloud instance types.

Widely used commercial packages—productivity suites, accounting software, CRM platforms—typically migrate without major issues because vendors actively support cloud and virtualized deployments. The real risk is proprietary line-of-business software developed years ago by vendors who may no longer be in business. Identify these applications early and plan remediation (rewrite, replace, or containerize) before the migration starts.

3. Do You Have a Disaster Recovery Plan?

A common misconception is that moving to the cloud eliminates the need for a disaster recovery (DR) plan. It does not. Cloud providers operate on a shared-responsibility model: the provider is responsible for the availability of the underlying infrastructure, but you remain responsible for your data, your application configuration, and your recovery procedures.

A cloud-native DR plan should address at least the following:

• Backup frequency and retention: Define recovery point objectives (RPOs) for every tier of data and confirm your backup schedule meets them.
• Cross-region replication: A single-region deployment is vulnerable to region-wide outages. Evaluate whether a multi-region or multi-cloud architecture is warranted.
• Tested restore procedures: Backups that have never been tested are not reliable. Schedule regular restore drills and document the results.
• Runbook documentation: Ensure your team can execute recovery steps without relying on institutional knowledge held by a single person.

Migrating to the cloud is an opportunity to build DR capabilities that would have been prohibitively expensive on-premises. Take advantage of it—but do so deliberately, not as an afterthought.

4. Should You Outsource or Handle It In-House?

It is tempting to treat cloud migration as an internal project that your existing engineering team can absorb alongside their regular workload. In practice, migration projects frequently underestimate the total effort involved: discovery and dependency mapping, environment provisioning, data transfer, testing, cutover, and post-migration stabilization all consume more time than initial estimates suggest.

Consider the following when making this decision:

• Team experience: Has your team executed a cloud migration of comparable scale before? Inexperience is the most common driver of extended downtime and cost overruns.
• Opportunity cost: What product work or operational improvements are delayed while your engineers focus on migration? Factor that into the true cost of the in-house option.
• Specialist partners: Cloud providers and independent managed service providers offer migration assessment and execution services. Engaging a partner with a proven methodology can compress the timeline and reduce risk, even if it increases upfront cost.

A hybrid approach is also viable: use an external partner for the initial migration and knowledge transfer, then transition operations to your internal team once the environment is stable.

5. What Will It Really Cost?

Cloud computing shifts spending from capital expenditure (servers, data center space, cooling) to operating expenditure (monthly consumption billing). That shift offers real financial flexibility, but it also introduces a new category of risk: unpredictable and sometimes rapidly growing cloud spend.

To build an accurate cost model, account for all of the following:

• Compute: Instance types, reserved versus on-demand pricing, and auto-scaling policies all affect your bill. Right-size instances based on actual workload data, not peak theoretical load.
• Storage: Object storage, block storage, and archival tiers have different per-GB costs and retrieval fees. Map your data access patterns before choosing storage classes.
• Egress: Data transfer out of the cloud is charged by most providers. High-egress workloads—large media files, frequent large API responses—can make cloud economics unfavorable without careful architecture.
• Licensing: Bring-your-own-license (BYOL) versus provider-managed licensing can have a significant cost difference for databases and enterprise software.
• Operational tooling: Monitoring, logging, security scanning, and cost management tools add to the monthly total.

Use your chosen provider’s cost calculator as a starting point, then validate against actual usage data once you have run workloads in the cloud for 30 to 60 days. Establish budget alerts and anomaly detection from day one to catch runaway spend before it becomes a problem.

Putting It All Together

A successful cloud migration is the product of deliberate planning, not just technical execution. By answering these five questions before you start, you give your team a realistic picture of the project scope, reduce the likelihood of costly surprises, and set a foundation for long-term cloud operational excellence.

Document your answers, share them with stakeholders, and revisit them as the project progresses. Requirements change, and a plan that was accurate in month one may need adjustment by month three. Build that flexibility in from the start.

Financial results for the fourth quarter of 2016 reveals massive growth for the top cloud providers. With 47% and 93% revenue growth for Amazon AWS and Microsoft respectively, one thing is clear – cloud is growing at a breakneck pace.

Enterprises and small businesses will continue to adopt and invest in cloud technology. Cisco’s Global Cloud Index whitepaper shows global cloud IP traffic will almost quadruple over the next five years.

But the rapid expansion of cloud has created a skills gap; there’s a lack of qualified cloud professionals. To support this growing demand, businesses require skilled cloud professionals.

Take advantage of this opportunity and expand your cloud skill set; how many of these in-demand skills do you possess?

Database and big data

It’s estimated that 80% of the world’s data is ‘dark’ – collected and stored by computers, but invisible and unusable to organisations.

Big data systems – delivered through the cloud – are starting to tap into this potential resource and the sector is predicted to grow at a rate of 60% annually, report IDC.

Experts argue that cloud will be the place where enterprise databases live – “The cloud is going to be the destination for a lot of this big data moving forward” says Jeff Kelly, big data expert at Wikibon.

Businesses need somewhere to store and access their data, which is now increasingly hosted in the public cloud. There are an abundance of cloud database services, provided by large cloud providers like Microsoft, Amazon AWS, and recently, Google. As organisations continue to migrate databases to the cloud, professionals should familiarise themselves with how these platforms work.

Amazon Web Services (AWS) provide Amazon Relational Database (RDS) which runs either MySQL, Oracle or SQL server instances. Alternatively, professionals can get to grips with the schema-less Amazon SimpleDB for smaller workloads.

Microsoft Azure uses SQL Database to provide access to a SQL database on the Azure platform, or a hosted SQL server instance on virtual machines.

Professionals can also opt for open source database platforms, like MongoDB. Learn how to code in Hadoop — a massively popular language used to process masses of data — and you’ll be well placed to take advantage of cloud’s big data revolution.

Luckily for professionals, database skills are well-supported by vendors. There are a number of database-focused Microsoft Azure certifications as well as the Big Data on AWS certification to support your learning.

There are also a huge breadth of big data and Hadoop MOOCs (Massively Open Online Courses) and certifications available from Cloudera.

Application security

As cyber threats become more complex and the number of businesses using the cloud attracts larger numbers of cyber criminals, cloud professionals must be increasingly vigilant when developing applications for the cloud.

The lack of thought given to security built into publicly used applications is a huge weakness, one that can be exploited by cyber criminals.

“On average there are now 777 cloud apps in use in European organisations, but 94.4% of these apps are not enterprise-ready from a security standpoint” states Eduard Meelhuysen, VP at cloud security firm Netskope.

Software developers must understand the security threats to software developed for cloud. It is ultimately the developer’s responsibility to ensure the security and compliance of their Azure applications.

Plus, when EU General Data Protection Regulation (GDPR) is introduced in 2018, Azure application security must improve or businesses will risk up to £17 million in fines.

However, with only 2% of cloud applications ready for GDPR, there’s a massive amount of work ahead for cloud professionals.

If you need to develop your security skills – or prove them to potential employers – consider attaining (ISC)2’s Certified Cloud Security Professional (CCSP) certification. This high-level certification is co-developed by the Cloud Security Alliance and provides an in-depth look at cloud application security.

Enterprise cloud migration

It’s not just small businesses that are migrating to the cloud, commercial enterprises are doing it too, and at an increasingly rapid rate.

Nearly 77% companies relied on traditional IT infrastructure in 2015. As large businesses migrate to cloud-based infrastructure, this number is likely to drop down to 43% in 2018, according to a report from MicKinsey’s Silicon Valley group.

But enterprises migrating their applications and services to the cloud continue to face roadblocks. Cloud migration challenges are among the top constraints for IT, according to a survey from Frost & Sullivan.

The cloud may offer some automated features, but migration is not one of them. This means that enterprises typically rely on customised, professional services from partners or providers.

Businesses require cloud professionals with the knowledge to oversee migration projects in an organised and secure way.

These professionals will also need in-depth knowledge of their chosen cloud platform. For Azure, professionals should consider attaining the Specialist: Implementing Microsoft Azure Infrastructure Solutions certification through the recommend Azure course.

Alternatively, AWS professionals should consider attaining the Certified Solutions Architect – Associate, which covers the process of shifting an existing on premise application to AWS.

Containers

The cloud computing industry has witnessed a surge in the use of containers, a more agile and secure alternative to VMs, designed to virtualise a single application. Containers are an ingenious way to develop and deploy micro-services, especially for cloud-based apps.

Whilst arguably not a career-defining skill for most, knowledge of containers is becoming increasingly important for cloud professionals. 81% of businesses suggested that they will increase use of containers in the future, according to a survey from Robin Systems.

Interestingly, 40% of respondents also said they had already deployed big data applications tools, like Spark and Hadoop in their containers.

Containers promise to make operations more portable and efficient. Impressively, the application container market will grow from £610 million in 2016 to £2.17 billion by 2020.

‘Containers will be used for deploying solutions to solve real-world business problems. Companies will use them to provide new services that are secure, efficient, elastic, and scalable,’ says Anand Krishnan, EVP and GM of cloud at Canonical

Amazon AWS and Microsoft provide container services and associated tutorials. Take a look at the Microsoft Virtual Academy for a detailed tutorial on Azure Container Service or the Amazon EC2 Container Service walkthrough.

Cloud enterprise application development

As more businesses launch public and private cloud initiatives, the importance of application development and testing in the cloud is increasing.

If applied properly, the cloud provides faster application development and can facilitate DevOps style collaboration. Other benefits include: using cloud features with minimal coding, reducing development time, and creating realistic distributed testing for application lifecycle management.

Amazon AWS supports development with the AWS SDK, enabling developers to code with Java, C#/.Net, Python and JavaScript. There’s also a AWS track for development and free training through a number of online self-paced labs.

Luckily, developers already familiar with Microsoft technologies, like the .NET framework and Visual Studio IDE, should find developing for Azure an easy transition. With solid infrastructure and service delivery guidelines behind Azure, most developers won’t need much more than their existing skills to get started building apps for Azure.