Why AWS is a Good Choice for Business-Critical Workloads

As cloud technologies mature, teams continue to work from home, and the confidence in public cloud increases, companies are moving more of their critical workloads into the cloud. Gartner forecasts that annual end-user spending on public cloud service will reach $396 (€334) billion this year, accounting for roughly 17% of IT spending, and that by 2026 over 45% of IT spending will go towards public cloud.

Cloud has Moved from Experimental to Business-critical

The majority of companies are already experimenting with cloud workloads, with 92% of IT-decision makers reporting to have some part of their business in the cloud according to the 2020 IDG Cloud Computing Survey, compared to 73% in IDG’s 2018 survey. 

However, the majority of those surveyed would still consider themselves “mostly on-premise” – and many are looking to change that over the next 18 months.

Many companies are now past the early, more experimental phase of cloud adoption where a point solution is implemented here or there. Public clouds like AWS have proven themselves, and teams have built up enough experience with them, that companies are more comfortable with the idea of running business-critical workloads in the cloud.  

This transition often not only requires a technology change but an organizational change for a business, and nobody wants a situation where all the effort to move the cloud is rolled back because the results don’t meet expectations. 

Having helped many multinational companies in different stages of cloud migration, we’ve seen that frustrated expectations often revolve around the most alluring benefits of the cloud: cost and scalability.

Glass Box Cost isn’t Automatic

Usage-based pricing is only advantageous when you know what you’re using. A recent survey by the FinOPs Foundation found that while 98% of respondents claim that predicting cloud bills is at least somewhat important, 21% of them do not (or can not) predict their bills at all. 

The service-based nature of the cloud means that it is possible to monitor your costs at a very granular level, but that view isn’t automatic. One of the ways we help companies build a more transparent FinOps model for their AWS workloads is by allocating costs at a purpose, owner, and environment level using AWS Tagging. 

A global tagging system can provide the visibility needed to make accurate forecasts, see where you’re overpaying, and continuously monitor and right size your AWS services. We’ve seen this visibility provide the foundational data needed for one multinational company to build a FinOps model that reduced their AWS cost by 45% in 10 months (a 7-figure difference) while seeing a 3x increase in traffic during the same period.

Here are a few of the AWS tools that we have found helpful to monitor costs:

• AWS Config: create an inventory of AWS resources
• AWS Cost Explorer: visual dashboard to monitor cost and usage 
• AWS Budgets: set custom budgets and automate actions if cost or usage exceeds thresholds 
• AWS Cost Anomaly Detection: monitor and alert for irregular spending via machine learning 
• AWS Cloudwatch: a unified view of operational health for resources, applications, and services
• AWS Compute Optimizer: machine learning recommendations for optimal AWS resources for your workloads
• AWS Trusted Advisor: scans your AWS infrastructure and compares to AWS best practices to make actionable recommendations

Modern Scale Requires Modern Architecture

Business-critical applications don’t just need to be able to scale, they need to do so in a way that is reliable and cost-effective. Lifting and shifting a legacy platform to the cloud might allow you to better provision resources for expected load peaks, but platforms designed to work on-premise aren’t able to take full advantage of the scaling toolkit that the cloud offers.

Solutions that are purpose-built for the cloud are designed so that every functionality is available via API, allowing companies to fully leverage modern technology strategies like containerization, headless frameworks, and edge computing. Solutions originally built as on-premise might be wrapped in APIs so that it can be hosted in the cloud, but the inner workings of these platforms tends to remain monolithic and can’t support the modern cloud strategies that are needed to scale business-critical services. 

For most companies, the transition to purpose-built cloud solutions happens in stages, and a benefit of the newer API-first solutions is that their modular features are designed to play nicely with other tools. Companies can gradually step off legacy platforms by replacing one capability at a time, avoiding a major re-platform effort, with the freedom to choose best-fit capabilities from multiple vendors. Ultimately, taking a composable approach to business that not only lets organizations scale-out technology and features easily, but also gives teams the tools to grow new revenue streams or into new markets. 

More and more, we see companies go composable by leveraging MACH technologies, which are not only purpose-built for the cloud but are microservice-based, API-first, cloud-native, headless solutions that power some of the most exciting digital initiatives on the market today. 

Cloud Best Practices for Business-critical Systems

At Mindcurv we’ve helped companies along the whole spectrum of cloud transition, from ones that are just starting to explore options to those who have already migrated and need to optimize their approach. 

Every company, of course, has a different path to cloud migration success based on their current setup, business challenges, and how they want their platform to evolve. However, there are a handful of foundational steps that we encourage nearly all of our clients to take when moving to the cloud.

Move Away from Outdated Software (and Go SaaS)

In an analysis of 5.6M websites over 18 months, researchers found that only 6% of websites were using exclusively up-to-date software, and 47% relied entirely on outdated software types. 

For many companies, the layers of dependencies and customization that have built up around legacy tools make updating a big enough burden that they risk the vulnerabilities of staying on outdated software. The manual work it would take to move these solutions to the cloud – and keep them up to date – just isn’t sustainable for most teams. 

This is one of the reasons why, whenever possible, we work with customers to find a cloud-native Software-as-a-Service (SaaS) alternative for critical business capabilities. Instead of releasing major and minor versions, SaaS solutions push out rolling, backward-compatible updates so companies are always using the most up-to-date version – no manual effort required.

Deploy Infrastructure as Code

The expectation of cloud is that companies can easily and automatically deploy environments at scale while the vendor, like AWS, does the heavy lifting of managing cloud infrastructure and data centers. Infrastructure as Code (IaC) is a method of managing and provisioning infrastructure that enables this. 

With IaC, there is a single configuration model that is used to provision all environments. As explained in a Microsoft post about IaC, “Without IaC, teams must maintain the settings of individual deployment environments. Over time, each environment becomes a snowflake, that is, a unique configuration that cannot be reproduced automatically. Inconsistency among environments leads to issues during deployments. With snowflakes, administration and maintenance of infrastructure involve manual processes which were hard to track and contributed to errors”.

By ensuring output infrastructure is always the same, IaC helps companies:

• Eliminate manual work needed to manage and provision for “snowflake” environments
• Quickly generate testing environments that are identical to live environments
• Simplify version control by making well-documented changes to the source, not target environments, that can be rolled back if necessary.

Build in Redundancy

Reliability is one of the 5 pillars of the AWS Well-Architected Framework and the main way to ensure your business-critical workloads are resilient is to cost-effectively build redundancy into your system with AWS Availability Zones. If you distribute your instances across multiple Availability Zones and one instance fails, an instance in another Availability Zone can handle requests. 

For example, when an AWS data center in Frankfurt had issues with air conditioning we were able to quickly move their Kubernetes Pods from a node in one Availability Zone to another, without downtime or impact to the customer.

AWS Migration Partners for Managing Critical Workloads

From assessing and planning, to executing the migration, to monitoring operations, having the support of an experienced partner can help organizations make a smooth transition to using AWS for business-critical workloads.  

Mincurv is recognized as an AWS Advanced Consulting Partner and Well-Architected Partner, with many years of experience in building mission-critical applications and infrastructure on AWS. We’ve helped leading companies like Vorwerk and Nikon Europe successfully move their infrastructure to AWS and would be happy to discuss the best approach for your business-critical solutions.

Tags AWS Migration, Business critical workloads, MACH, Organizational Improvement