Amazon as an enterprise has rapidly evolved from the challenges it endured that could neither have been addressed technically nor economically at the time when running large-scale applications. This fact may have led us to conclude that AWS was unlikely to develop a product that would resemble a traditional server rack you could find in any regular data center.

As with any market or industry, things change. New technologies arise, paradigms shift, and new trends pose new challenges and require new solutions. It was no different from the way enterprises consume corporate IT services. In the past couple of years, the hybrid phenomenon gained a lot of momentum to become one of the preferred ways for enterprises to run their business.

This is not strange by any means. You have the start-up sector, which is cloud-native and certainly does not see any reason to have a physical infrastructure of its own. Start-up companies only need a solid connection to the internet and personal equipment to carry out the development work and the administrative work with cloud providers.

At the other end of the spectrum, we had companies over the past few decades doing IT the traditional way, operating fully on-premises. But in recent years, the market has developed the perception that it does not need to be one way or the other.

Back then, your option to run IT infrastructure outside your own local data center relied on offerings from third-party specialized data center providers. Offerings such as hosting, location, and co-location were extremely popular at the time, and are still available today. If you could order a good leased line to connect your site(s) with the provider’s site, any of the options would be available to you.

At best, you could have one of these providers supplying and managing all the necessary equipment to run your business while leveraging the OPEX financial model. Your IT team would take care of services and Line-Of-Business (LOB) applications and you would be in business. For some companies, the CAPEX model made sense as purchased equipment became assets for the company and added value to the balance sheets.

Times change and the advent of the cloud challenged the constraints and limitations of traditional data centers. Andrew Jassy, currently the president and CEO of Amazon, in an interview for the site TechCrunch (https://techcrunch.com/2016/07/02/andy-jassys-brief-history-of-the-genesis-of-aws/), described how AWS was conceived to be the Operating System for the internet at its inception, designed to reliably run applications and services at massive scale.

When AWS came to life in 2006, it wasn’t too clear that it would become what it is today. From humble beginnings with no clear ambition and marketing to turning into a cloud behemoth just 15 years later, AWS and the cloud were just yet another technology trend that remained to prove reliable and solid. The early adopters pioneered the new cloud paradigm and got their feet wet with infrastructure and services that existed beyond their reach when they could not even schedule a visit to the data center.

Adopting cloud services was an exercise of a dual IT landscape design. Either one given service lived on-premises or lived in the cloud. The connection between the two was basically to exchange data for migration or backup and, eventually, very simple interaction between systems with multiple components. It was difficult to consider a three-tier architecture where one of the tiers would sit in the cloud with the other on-premises. Internet bandwidth was scarce, connections were not strongly reliable, and you often had to resort to VPNs for security because it was challenging to procure dedicated links to directly connect with cloud providers at the time.

As the cloud trend reached critical mass and established itself as a valid path, businesses faced a new reality: the cloud had to be considered within their technology plans and a thorough assessment of the IT landscape was necessary to devise a strategy that could somehow encompass cloud offerings and to a serious extent. A vague statement about the cloud just being hype was no longer acceptable to business owners – it was here to stay.

This new way of consuming corporate IT services was dubbed hybrid cloud and described as a combination of cloud services running alongside the traditional on-premises data center solutions. Not surprisingly, the point of view of this model was oriented from the data center out into the outside world, stretching toward the cloud, because it was primarily articulated by on-premises infrastructure providers whose vision centered around the traditional model.

The possibility of a business going all in with the cloud while shutting down all traditional data centers was somewhat far-fetched, but it was delineated as a real alternative. While it is clear that not all workloads will be a fit for the cloud and some may remain on-premises, a significant shift of IT infrastructure to the cloud can realistically be envisioned.

Further developments in this trend revealed that one piece of the puzzle was missing. If considered as a binary choice, an on-premises data center versus the cloud, any move could be a significant risk because there was no middle ground. IT teams were facing an all-or-nothing situation where systems with multiple components would have to be moved as a whole, likely in one go.

Evaluating how a system would perform when running on the cloud was complex because tests had to be carried out in terms of production size and capacity without close contact with all other surrounding systems and services. Even with extensible tests, a cutover date was an event of high significance, full of anxiety, and likely to have a long maintenance window. Clearly, an intermediary infrastructure bridging both worlds would be beneficial.

Initial attempts to fill this gap were made by traditional software providers, offering solutions to be run on-premises that used the type of technologies and solutions offered by cloud providers. This was the private cloud – one attempt to bring the cloud operational model to customer on-premises data centers. Running on their own infrastructure at their data centers or co-location sites, the promise was to leverage cloud-like services and technologies at your facility or closer to you.

It was a good approach and makes good sense. IT teams can become familiar with cloud technologies and how system operations are carried out in the cloud while relatively comfortable at home with their own equipment, learning at their own pace. As IT professionals became familiar with the cloud model, the transition to a cloud provider could be facilitated as the value and challenges became clearer.

Even with a good portion of the market leveraging the private cloud offering, there was still the inescapable fact that on-premises, you could not leverage the cloud-specific services and technologies. Moreover, you would never benefit from the scalability and economies of scale offered by cloud providers. It was you running cloud-like services and still managing the necessary infrastructure.

Cloud adoption has gained significant momentum in recent years and we can see now how start-up companies are said to be born in the cloud or cloud natives. These businesses would have never considered creating their products and applications using the on-premises infrastructure. Such offerings would not be possible if they were conceived within the limitations and paradigms of traditional technologies.

Systems have become increasingly complex, made up of many moving parts as opposed to the monolithic approach of yesterday. Technologies favored distributed systems and highly specialized and smaller microservices. This movement highly favored the appeal of the cloud, built on top of pay-per-use, faster innovation, elasticity, and scale. For more information, refer to this video (https://www.youtube.com/watch?v=yMJ75k9X5_8), The Six Main Benefits of Cloud Computing.

Fast forward to today and considering the latest world developments, the cloud has completely solidified its position and, to be fair, has exploded in adoption, which was significantly accelerated because of the challenges imposed by recent events such as the pandemic. The cloud model was battle-tested and made it through, to the point that it became the de facto standard model to be considered the foundation of technology.

While the future of the cloud seems to be clear skies, there is another fact that still holds: the vast majority of IT spending is still on traditional infrastructure and data centers. While this seems to be a wonderful opportunity to thrive in a market where the largest chunk of business is yet to be conquered, it also means that the missing key piece to act as the catalyst for the widespread adoption of the cloud is more crucial than ever.

As the next step toward blurring the boundaries between the cloud and the so-called physical world, the concept of a hybrid has been redefined. Hybrid is considered to be this enabler, the indistinguishable middle ground where on-premises and the cloud live together in a harmonic symbiosis where both parties benefit from each other. To amplify that notion, the term edge was added to the vernacular.

What we are now seeing is the original hybrid concept in reverse. Now, it originates in the cloud and branches out to the world in the form of edge nodes, where any given data center is considered to be one of these nodes. Effectively, the cloud aims to be everywhere, encompassing all kinds of businesses and places, powered by the recent advancements in high-speed wireless connectivity through 5G networks and IoT devices and sensors.

To make it clearer, an edge node is considered to be anywhere you could run some form of computing, be it large, small, or tiny. Naturally, a family house, a hospital, a restaurant, a crop field, an underground mine, and a cargo ship are significantly different places in nature. Suitability to accommodate electronic components and connectivity conditions change radically and the mileage of the IT equipment running will vary.

To describe these components better when deployed in harmful and aggressive environments, this space is conceptualized as the rugged edge, where equipment must withstand harsh usage conditions and must incorporate design characteristics and features that allow prolonged, normal operation under those circumstances. Equipment built for this purpose boasts specs that allow for severe thermal, mechanical, and environmental conditions.

Today, cloud companies are challenging themselves to create technologies that will propel the ultra-connected world where technology is pervasive, data is collected massively everywhere, and information is nearly real-time. Hybrid solutions play a fundamental role in this game, paving the way for cloud providers to extend all over the world and become the infrastructure, not one infrastructure.

For years, AWS was clear on its messaging that customers should stop spending money on undifferentiated heavy lifting. This is AWS verbatim, as can be seen in the design principles for the Cost Optimization pillar of the AWS Well-Architected Framework (https://docs.aws.amazon.com/wellarchitected/latest/framework/cost-dp.html). As it says, racking, stacking, and powering servers fall into this category, with customers advised to explore managed services to focus on business objectives rather than IT infrastructure.

From that statement, it would be reasonable to conclude that AWS would hardly give customers an offering that could resemble the dreaded kind of equipment that needs power, racking, and stacking. The early strides of AWS bringing physical equipment to customers were in the form of the AWS Snow family: AWS Snowball Edge devices and their variants (computing, data transfer, and storage).

It does sport the title of being the first product that could run AWS compute technology on customer premises, being able to deliver compute using specific Amazon Elastic Compute Cloud (EC2) instance types and the AWS Lambda function, locally powered by AWS IoT Greengrass functions. Despite this fact, it was advertised as a migration device that enabled customers to move large local datasets to and from the cloud, supporting independent local workloads in remote locations.

In addition, Snowball Edge devices can be clustered together and locally grow or shrink storage and compute jobs on demand. AWS Snowball Edge supports a subset of Amazon Simple Storage Service (S3) APIs for data transfer. Being able to create users and generate AWS Identity and Access Management (IAM) keys locally, it can run in disconnected environments and has Graphic Processing Unit (GPU) options.

Launched in 2015, the first generation was called AWS Snowball and did not have compute capabilities, which would appear in 2016 when the product was rebranded as Snowball Edge. Today, AWS Snowball refers to the name of the overall service. The specs are impressive, with 100 GB network options and the ability to cluster up to 400 TB of S3 compatible storage. SBE-C instances are no less impressive, featuring 52 vCPUs and 208 GB of memory.

AWS invested a great deal to make the cloud not only appealing but also accessible. Remove that scary thought of having to change something drastically and radically, that awful sensation of having to rebuild the IT infrastructure on top of a completely different platform. AWS even gave various customers a soft landing and easy path to AWS when they announced (https://aws.amazon.com/blogs/aws/in-the-works-vmware-cloud-on-aws/) their joint work with VMware in 2016 to bring its capabilities to the cloud, which debuted in 2017 (https://aws.amazon.com/blogs/aws/vmware-cloud-on-aws-now-available/).

With these capabilities and Edge appended to the service name, it seemed that moving forward, the path was set with Snowball. It was not without surprise that AWS Outposts was announced in November 2018 during Andy Jassy’s keynote at re:Invent. On stage, it was shown as a conceptualized model, but one could clearly see it had the shape and form of a server rack.

AWS Outposts debuted on video in 2019 (https://youtu.be/Q6OgRawyjIQ), introduced by Anthony Liguori, the VP and distinguished engineer at AWS. By that time, it became clear that a server rack was in the making inside AWS and it was targeting the traditional data center realm. However, it was against the AWS philosophy of asking customers to stop spending money on traditional infrastructure. Anyone staring at an AWS Outposts rack could be intrigued.

At re:Invent in 2019, Andy Jassy revealed the use case for Outposts during his keynote. He started by acknowledging some workloads that would have to remain on-premises because even companies who had been strong advocates for cloud adoption had also struggled at times to move certain workloads that proved to be very challenging, and eventually stumbled along their way.

Outposts was characterized as a solution to run AWS infrastructure on-premises for a truly consistent hybrid experience. The feature set was enticing: the same hardware that AWS runs on its data centers, seamlessly connecting to all AWS services, with the same APIs, control plane, functionality, and tools as used when operating in the Region. On top of it, it is fully managed by AWS. In the same opportunity, he showcased one specific Outposts variant for VMware, which was a bold move for a cloud company advocating to stop investing in data centers.

That was not the only announcement targeting the edge space. At that same event, AWS Local Zones and AWS Wavelength were announced. While these offerings fall beyond the scope of this book, it’s worth noting that they weave together to compound an array of capabilities to address the requirements and gaps in the edge space and get a strong foothold in it. So, it suffices to say, AWS Local Zones are built using slightly modified (multi-tenant) AWS Outposts racks.

Now, we have finally set the stage to introduce AWS Outposts. Let us begin with the product landing page (https://aws.amazon.com/outposts/). At the time of writing, it is now dubbed Outposts Family, due to the introduction of two new form factors at re:Invent in 2021. The 42U Rack version, the first to be launched, is now called an AWS Outposts rack. The new 1U and 2U versions are called AWS Outposts servers.

Regardless of family type, three outstanding statements that are valid across the family and strongly establish the value proposition of this offering:

• Fully managed infrastructure: Operated, monitored, patched, and serviced by AWS
• Run AWS Services on-premises: The same infrastructure as used in AWS data centers, built on top of the AWS Nitro System
• Truly consistent hybrid experience: The same APIs and tools used in the region, a single pane of management for a seamless experience

Let us cover each in detail.

One of the key aspects of positioning AWS Outposts in customer conversations revolves around explaining how AWS Outposts is different from ordering commodity hardware from traditional hardware vendors. That is exactly where these three statements come into play, highlighting differentiators that cannot be matched by competing offerings.

AWS Outposts is fully managed by AWS. While others may claim their products are also fully managed, AWS takes it to the ultimate level: it is an AWS product end to end. The hardware is AWS, purchase and delivery are managed and conducted by AWS, product requirements are strongly enforced by AWS, and site survey, installation, and servicing are conducted by AWS. No third parties are involved – the customer’s point of contact is AWS.

AWS Outposts enables customers to run a subset of AWS services on-premises and allows applications running on Outposts to seamlessly integrate with AWS products in the region. Single-handedly, the first line itself knocks out traditional hardware. For example, you can’t run EC2 on it. To amend the case, while applications running on traditional hardware can interact with AWS via API calls, AWS Outposts once again takes it to a whole new level, stretching an AWS Availability Zone in a given Region to the confines of an Outposts rack, allowing workloads to operate as if they lived in the same Region.

Customers are extremely sensitive to consistent processes. The use of multiple tools, multiple management consoles, and various scripting languages is cumbersome and error-prone. When you craft a solution where multiple parts come from multiple vendors and are all assembled, that is what ends up happening.

You will need to use a myriad of tools, interfaces, and scripts to configure and make it work. Long and complex setup processes, multiple vendors involved in troubleshooting errors, and multiple teams conducting various stages of the process lead to inefficiency, inconsistency, security problems, and significant delays in being ready for production.

IT professionals normally try to avoid this pitfall by pursuing a solution provided by a single vendor, even with the risk of the infamous single vendor lock-in. However, one hardware provider hardly ever designs and manufactures all the constituent technologies involved, such as the compute, storage, networking, power, cooling, and rack structures. More often than not, the OEM of some of the components is a third-party vendor, if not a third-party brand itself. In the end, these solutions are a collection of individual parts with some degree of consistency.

Here is another significant differentiator of AWS Outposts, which is a thoroughbred AWS solution. AWS Outposts employs the same technology used in AWS data centers whose hardware designs and solutions have undergone significant advancements over time and have been battle-tested in production for several years. With this level of integration and control, AWS can explore and tweak the components for highly specialized tasks, as opposed to the more general-purpose approach of commodity hardware.

AWS developed a technology called the AWS Nitro System (https://aws.amazon.com/ec2/nitro/), which is a set of custom application-specific integrated circuits (ASICs) dedicated to handling very specialized functions. AWS Outposts uses the same technology, standing in line to receive any of the latest and greatest advancements AWS can bring into the hardware technology space. Being such a uniform and purpose-built solution, it benefits from a fully automated, zero-touch deployment for maximum frictionless operations.

Now, we are equipped to widely understand the AWS Outposts offering as a stepping stone deployed outside the AWS cloud, with strong network connection requirements to an AWS Region, capable of running a subset of AWS services and capabilities, and conceived and designed by AWS with its own DNA.

AWS Outposts is not a hardware sell, it is not a general-purpose infrastructure to deploy traditional software solutions, and it is not meant to run disconnected from an AWS Region. AWS Outposts is a cloud adoption decision because you are running your workloads not in a cloud-like infrastructure but rather, in a downscaled cloud infrastructure. This is evident because, during the due-diligence phase, an AWS Outposts opportunity can be disqualified by the field teams if the customer workloads are capable of running in an AWS Region. AWS believes in the philosophy that if workloads are capable of running in AWS Region, they should run in an AWS Region.

Basically, AWS is asking what the use cases and business requirements are that prevent certain workloads from operating in the cloud, something that could defy common sense. Does that mean AWS is trying to discourage the customers from taking the Outposts route in favor of bringing them from the edge to the core Region?

Very much the reverse – AWS wants to make sure customers are making informed decisions. It wants them to understand the use cases for Outposts. Fundamentally, they understand they are effectively setting foot in the cloud with Outposts being the enabler to galvanize cloud adoption and the catalyst for companies to upskill their teams to build a cloud operations model and become trained in AWS technologies and services.

At this point, you should be able to identify the edge IT space, the gap between the cloud and the on-premises data center, and also understand the historical challenges associated with operating infrastructure spanning these significantly different domains.

As the initial solutions to address this problem were not good enough, AWS developed Outposts to be the answer to seamlessly bridging these two worlds. Now, it is time to frame AWS Outposts in this edge space to see how it handles the assignment.