DEV Community: Interrupt

re:Invent Revisited - AWS Fargate

Interrupt — Thu, 26 Nov 2020 01:38:59 +0000

The 2017 edition of re:Invent had some great announcements. In my previous post we looked at the 2017 announcement of AppSync which didn’t make a keynote. In this post we’re looking at AWS Fargate, announced in Andy Jassy’s keynote, then revisited in Werner’s never ending keynote the next day by Abby Fuller.

In the same keynote AWS’s managed Kubernetes service Amazon Elastic Kubernetes Service (EKS) was announced. AWS launching a managed Kubernetes service was always expected. It would have been a bigger announcement if they didn’t launch something in that space. For AWS launching a managed version of an open source project is an acknowledgement they have enough customers running that software themselves that would prefer AWS to run it for them.

There is a growing number of AWS customers that choose Fargate as their first destination when migrating to container based infrastructure. Vanguard got on the re:Invent stage in 2019 to talk about their AWS migration, with Fargate providing an easy migration target for their existing aPaaS. They skipped the Kubernetes learning curve, and lifted their entire aPaaS into Fargate. Far from alone, organisations as diverse as Samsung Electronics to Square have migrated significant infrastructure to Fargate.

I see Fargate as the next generation of EC2. EC2 abstracts away hypervisor management and removes management of underlying physical infrastructure from end users. Fargate abstracts away container orchestration management plane and removes management of underlying virtual machines.

With Fargate the major difference between the two is application encapsulation at container not virtual machine level, resulting in a lightweight portable artifact, with a trade off on constraints on operating system choice. Unfortunately that Windows NT 3.51 VM that should have died in a fire 15 years ago cannot live on in Fargate. The upshot of this is Fargate provides significant cost reductions over virtual machines, improved performance and agility, without the overhead of thinking about container orchestration.

AWS Fargate is not first to market. Microsoft Azure Container Instances (ACI) is similar and predates it. Predating both is Hyper.sh’s Secure Container Platform. Like Iron.io, a startup that pioneered Functions as a Service before AWS, Hyper.sh no longer exists. It’s engineering group quietly moved Ant Financial Group some time in 2019.

Early container implementations had the problem of not providing the same level of isolation as virtual machine hypervisors. This limited the adoption of containers in secure environments. Hyper.sh provided a solution to this by creating their ownOCI compliant container runtime,runV, that would run on top of a lightweight hypervisor. This provided a lightweight VM with a container interface, but all the security and isolation of a virtual machine. In conjunction with Intel in 2017, Hyper.sh open sourced this approach through the Kata Containers project. Not surprisingly Ant Financial Group are a large user of Kata Containers.

At re:Invent 2018 AWS announced the Firecracker microVM. A lightweight hypervisor written in Rust, used by AWS Fargate and AWS Lambda. Under the hood AWS Fargate borrows a lot of the concepts from Kata Containers and the original Hyper.sh platform. An OCI compliant container runtime on top of a lightweight VM, albeit with a tech stack they’ve created.

In a full circle moment, Kata Containers now supports the Firecracker microVM, and Ant Financial Group, with the old Hyper.sh engineering team, areusing it today.

I predict AWS Fargate is the future of container infrastructure. For the same reasons that EC2 displaced VMware’s vSphere as the VM platform of choice, Fargate will become the container platform of choice, displacing Kubernetes. It provides all the security of a VM, with the benefits of a container, with none of the management of an orchestration platform.

re:Invent Revisited - AWS AppSync

Interrupt — Tue, 24 Nov 2020 22:50:02 +0000

The volume of product announcements at re:Invent is huge. In the first few years of re:Invent product announcements were made during one of the keynotes from Andy Jassy or Werner Vogels. I think it was the 2014 re:Invent that they started to push smaller announcements to Jeff Barr’s blog in the days leading up to re:Invent.

By 2017, they had created the re:Invent Launchpad. A Twitch stream that ran throughout the conference to launch products that didn’t make a keynote, or go into more detail on products announced in the keynote. It was at the re:Invent Launchpad that AWS AppSync launched.

You can watch the launch here, featuring Tara Walker and Richard Threlkeld.

re:Invent Launchpad 2017 - AWS AppSync Announcement

I remember watching this launch live on Twitch, whilst sitting on the floor waiting in the queue to get into a re:Invent session. I loved this style of launch because they went into more depth than you could ever go into a keynote trying to launch 10 products in 2 hours. I was surprised at the time it didn’t make the keynote, and considering how much AppSync has grown I’m even more surprised now.

At its core AppSync is a managed GraphQL service. GraphQL was developed by Facebook engineers in 2012, and released as an Open Source project in 2015. GraphQL has quickly become the preferred way for web and mobile developers to interface with backend systems.

For the front-end developer GraphQL simplifies development. On the backend however, implementing a scalable GraphQL API yourself does not have the same ease. AppSync takes away the pain of running a GraphQL API, and has introduced AWS to a whole new generation of front-end developers.

In the early days of AWS, they supported SOAP and REST API’s. In his 2006 interview with ACM, Werner Vogels talked about how a small group of REST evangelists used AWS’s REST APIs.

“A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find.” - Werner Vogels, “A conversation with Werner Vogels” ACM Queue 30 June 2006, https://queue.acm.org/detail.cfm?id=1142065

In 2006 REST was the new interface standard popular with PHP developers driving the web revolution at the time. In 2020 GraphQL is the interface of choice with the new wave of developers rewriting the web in JavaScript.

AppSync is bringing a new generation of web developers into AWS, dramatically reducing the time and effort to design, deploy and run GraphQL APIs at scale. For this new generation of developers, it will be completely normal for a single developer to create and run an application end to end by themselves.

For experienced serverless hands likeYan Cui, AppSync takes the Serverless paradigm to the next level. In 2016 he was part of a team thatbuilt a serverless social network using API Gateway and Lambda in 6 months. In 2020 hebuilt a social network by himself in 4 weeks using AppSync.

For 2020 I’d like to see

Greater language support for GraphQL resolvers beyond the current use of Velocity Template Language
Schema Federation to allow multiple development teams to work on their own schema but publish a single federated schema via a single AppSync endpoint
PCI DSS compliance to allow the use of AppSync in card payment environments
Custom Authorizers that mimic the API Gateway Lambda Custom Authorizers

I expect to see AppSync’s usage to accelerate as a broader feature set enables it to appeal to a wider audience. The AppSync team have done a great job pushing the "do more with less" paradigm, and I expect this service has only just started on its growth trajectory.

Containers + Serverless: Cloud Native Bimodal

Interrupt — Mon, 23 Nov 2020 21:17:29 +0000

Around 2015, Gartner started to promote the idea of a bimodal IT organisation, with mode 1 effectively being ‘as is’ operations for existing infrastructure, and mode 2 being newer, modern, agile techniques and platforms.

A bimodal approach has the effect of promoting the idea that legacy infrastructure and operations are sufficient for existing systems, whilst supporting the innovation lab movement, which for most corporations is innovation theatre, at a hefty cost with little return. This approach prevents any real change in organisations, and in a world where the majority of IT budgets are spent on maintenance of existing infrastructure, it does little reduce that.

In the Gartner definition of Bimodal, the use of container and serverless technologies would be in the mode 2 operations bucket. That’s where new agile platforms and associated operational practices are used for new initiatives. Real world use tells a different story. The organisations reaping the most benefit from cloud platforms and agile operations are those that go all in.

Two case studies that prove big doesn’t mean hamstrung

Nordstrom, the 119 year old, $15 billion-a-year revenue retailer publicly stated they were going all in on AWS in 2015. Initially, they started down the route of many organisations moving to AWS, implementing automation and tools like Chef to automate their VMs in the cloud. At the same time container and serverless technologies were emerging. Nordstrom adopted both. Their first foray into containers was their homegrown container management solution, which has since been superseded by Kubernetes. They’ve achieved significant agility, with faster deploys and greater developer independence, whilst reducing their EC2 bill with AWS. Containers helped drive efficiency in their existing applications, without a major refactor. At the same time they were pioneering event driving architectures using serverless technologies, bringing new capabilities to the business. Doing all of this with a singular operational model of small teams, and developers pushing code to production via git-based workflows.

By using a singular operational model, container based platforms to drive efficiency and agility in existing applications, and serverless platforms to take advantage of new event driven paradigms, Nordstrom is able to be more responsive to its business needs whilst reducing costs, improving reliability and agility.

Nordstrom is far from alone in this. Vanguard, the 45 year old fund manager with $6.2 trillion assets under management, got up on stage at re:Invent 2019 to talk about their migration to AWS. The migration enabled them to “reduce the cost of computing 30 percent and deploy workloads up to 20 times faster, as well as improve resiliency and innovate quickly”. Like Nordstrom, Vanguard adopted a singular operational model, using containers (in the form of AWS Fargate) to drive efficiency in their existing applications, and leverage the event-driven nature of serverless platforms for stream processing.

Jeff Dowds, IT Executive at Vanguard showing a high level view of the Vanguard infrastructure at re:Invent 2019

These organisations are hardly alone. DataDog’s State of Serverless report found that 80% of AWS customers they surveyed who are using containers also used AWS Lambda. Containers + serverless is the norm, not the exception.

This is the cloud native pattern that works. A singular operational model with small empowered teams. Containers to drive efficiency in your existing applications, and Serverless architectures to become event driven.

Why use both?

Why is this the model? Why not use containers for everything? Why not serverless all the things? Why not different operational models for the different areas?

A singular operational model is key. The DevOps Research Agency (DORA) in its annual State of DevOps report identifies organisations into four clusters of operational practices: low, medium, high and elite. The organisations that are successfully achieving the outcomes of improved efficiency and agility whilst reducing costs share the same characteristics of high and elite performers. The 2018 DORA State of DevOps report found that an elite performer’s use of cloud was 23x more likely to meet the five cloud characteristics of on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service as identified in the NIST definition of cloud. The 2019 report found this had grown to 24x more likely. Essentially, elite performers were significantly more likely to fully utilise the cloud.

By adopting the practices of an elite performing organisation you will be in a better place to leverage container and serverless cloud native platforms.

A different type of bimodality

The decision when to use a container or a serverless platform has some nuance to it. Containers are a great place to replatform existing applications. They give you isolation, a portable image format, and great resource efficiency; all of which can be achieved without rewriting any application code.

Serverless applications on the other hand give you all those same benefits, but to a greater extent, combined with the advantage of being truly event driven and pay per use, with the caveat that the application model will require a refactor in most cases.

Serverless applications have a lower cost and operational overhead than any other model, but they come with the cost of significant change. When it comes to migration, the tension between these factors comes into play with containers often winning because the cost of change to serverless outweighs the benefit. Serverless migrations are most common when there is another driver to refactor an application beyond replatforming for efficiency.

Cloud Native Bimodal is a strategy to leverage containers and serverless cloud platforms under a singular operational model, to drive agility and efficiency to better meet the needs of the organisation.

Containers allow you to migrate quickly, serverless allows you to push your architecture further. Cloud Native Bimodal will dramatically improve the ability of your technology investment to meet your business needs.

re:Invent Revisited - The Amazon Builders Library

Interrupt — Mon, 23 Nov 2020 20:28:20 +0000

We’re kicking off a week of looking back at announcements from previous re:Invents, as we build up to re:Invent 2020. We’re starting with one of my favourite announcements of re:Invent 2019, the Amazon Builders’ Library.

Amazon and AWS have been very closed about how they build things. Werner Vogels has shared some insights up on stage during his keynotes over the years. Occasionally a research paper appears (The Dynamo Paper,Millions of Tiny Databases). Historically though, they haven’t shared much about how they build systems.

The lessons from building the Amazon platform over the previous 24 years had been to a large extent kept out of sight. This2006 interview with Werner is one of the best examples of Amazon sharing, albeit at a high level, how they operate. It’s been too rare an act of sharing. Amazon were very early adopters of service orientated architecture, they used small autonomous teams, adopted asynchronous processing through the use of queues, and many more. All before the general tech community had given these concepts the names we now use.

The Amazon Builders’ Library announcement changed that. It’s a collection of technical articles on how AWS builds systems. It’s written by AWS’s engineering team building the systems that run AWS. It was evenpositively received on Hacker News.

It gives consumers of AWS services a look at some of the design decisions behind the services they use everyday.This helps in many ways. It helps you understand how the services you consume work and where their boundaries are. It helps you learn architectural patterns and techniques you can apply in your own architecture.

It also helps AWS establish their tech credentials, which is good for hiring, and gives customers a warm fuzzy feeling that they’re working for a partner that lives up to their own marketing.

The pace at which its updated with new articles since launch has been slow. To date, it hosts 17 written articles and 6 videos. I assume this slower pace of release is a byproduct of using a small pool of principal engineers who write the articles, combined with the fact that the Builders’ Library is not their core role.

My hope for 2021 and the Amazon Builders’ Library is for an expanded pool of engineers writing articles giving us a deeper view of other parts of the AWS platforms, and for AWS clients to start publishing similar quality technical articles.

The Builders' Library goes deep in a limited number of areas, but expanding width of areas it goes deep into, the more invaluable it will become.

Check it out here.https://aws.amazon.com/builders-library.