rschick | Intro to ampt

If you build cloud applications you should already be familiar with Infrastructure as Code (IaC). In this article I will introduce you to Infrastructure from Code (IfC) and the Ampt cloud automation system.

Disclaimer: I am one of the founders of Ampt so the examples in the article will use it. However, the dicussion of IfC vs. IaC and the concepts are applicable to other IfC tools as well.

Target audience

This is an introductory article intended for cloud developers that are already familiar with IaC and use tools like Terraform, Pulumi or CDK to provision their cloud infrastructure.

What is Infrastructure from Code (IfC)?

Infrastructure from Code (IfC) and Infrastructure as Code (IaC) are both approaches to cloud automation. They both solve the problem of how to provision cloud infrastructure in a safe and repeatable way. The difference lies in how you define your infrastructure: IaC is explicit and IfC is implicit. I encourage you to read Gregor Hohpe’s excellent article on IaC and IfC trends and the differences between explicit and implicit infrastructure representation.

Note that these two approaches are not mutually exclusive. You can use IfC to provision some of your infrastructure and IaC to provision the rest. In fact, IfC actually uses IaC to provision infrastructure, so it’s more accurate to say that IfC is a layer on top of IaC.

One way to think of IfC is as a compiler that converts application code into “Function Code” and “IaC code” which can then be deployed using an IaC tool.

In the case of IaC, you write your application directly as “Function Code” that can be deployed into your provisioned infrastructure. You may also use a build step, but your code has to be aware of:

execution context - is the code running directly in a VM, in a container or in a Lambda function?
integration method - how is your code connected to the underlying infrastructure?

In the case of IfC, your application code is less concerned with where it’s running and how it’s integrated with infrastructure. I won’t go so far as to say it’s completely decoupled from your infrastructure, but it is less coupled in the sense that the interfaces your application uses are simpler and hide certain implementation details.

Let’s take a look at a concrete example using Ampt.

IfC with Ampt

Ampt is a set of tools and a service that lets you build cloud applications using familiar JavaScript and TypeScript (with more languages planned). It’s made up of a few different components:

The Ampt Service and API for provisioning infrastructure and deploying your applications.
A dashboard where you can manage your applications, environments, user permissions, and so on.
A CLI that interacts with the API to provision infrastructure and deploy your application code. It syncs code to developer “sandbox” environments so you can quickly iterate on your code, and has commands to deploy and manage long lived environments.
A Node.js-based runtime that runs your code and provides the runtime interface to the underlying cloud resources.
A set of libraries that provide a higher level interface to cloud resources like DynamoDB, S3, SQS, SNS, EventBridge, and more.

Here’s the (very) high level view:

Let’s look at an example to see how Ampt works.

One of the things almost every cloud application needs is an API. Here’s how you would define a simple to-do API using Ampt:

index.ts

import { api } from '@ampt/api'
const todos = api().router('/todos')
todos.get('/:id', async (event) => {
  const item = await getItem(event.params.id)
  if (!item) {
    return event.status(404)
  }
  return event.body({ item })
})

You can see that the code defines a REST API. It uses the @ampt/api library, but you could also use other web frameworks like Express if you want.

What infrastructure is required to run this?

One of the big challenges with building an application like this in AWS (and other cloud providers too) is that there are multiple ways you could build this:

You could run it on a single EC2 instance.
You could run it on a serverless platform like Lambda and API Gateway.
You could run it on a container platform like ECS or EKS.
You could run it on a managed service like App Runner.
and so on…

The cognitive load of all these decisions is massive. At Ampt we know this from experience building systems on AWS using a variety of different approaches.

We built Ampt because the answer to the above questions is “it depends”:

What are your performance and availability requirements?
What is the expected load?
What is your budget?

By deferring these decisions to a service like Ampt you can focus on your business logic and let the platform figure out the best way to run it. This is the essence of IfC.

Optimizing over time

The other challenge with building a cloud application (or any application really) is that requirements change over time. For example, your budget and expected load as a young startup will change when you grow and need to support more and more customers.

You can handle evolving requirements using traditional IaC: refactor or rearchitect your infrastructure to account for the changing requirements. Then update your function code to account for the change in infrastructure.

Using Ampt helps to minimize the impact of those evolutionary changes, using an infrastructure optimization loop.

Ampt monitors your live system, and can react to changes in load. It can optimize your infrastructure over time in response to other factors as well, such as:

AWS service changes, including changes to how they work, what versions are available, and pricing.
Changes in best practices as they relate to security, performance, and cost.

Conclusion

In this article I introduced you to the concept of Infrastructure from Code and how it related to Infrastructure as Code. I showed that IfC has several advantages over IaC:

It removes the need to explicitly model your infrastructure, so there are fewer libraries and languages to learn, and less code to write and maintain.
It can make your application code more portable, as it will be less coupled to a specific cloud provider.
IfC providers can optimize the infrastructure over time. For example, the infrastructure can be optimized for cost, improved performance and security.

That said, IfC is not a silver bullet. It has several limitations:

Depending on the tool, it may not support the full range of cloud infrastructure that you need. For example, Ampt creates an HTTP endpoint for you, and can provision DynamoDB, SQL, S3 buckets, and SQS queues. But if your application needs another service like Kinesis streams or OpenSearch, you’ll need to use an IaC tool to provison them.
Some IfC tools like Ampt use popular languages like JavaScript or TypeScript, but use a specialized runtime and libraries, so your application is coupled to the specific runtime. If you decide to switch to another tool or platform, you’ll need to port your code to the new runtime.

As with any tool or platform, you as a developer need to weigh the pros and cons and decide if it satisfies the requirements of your project.

If you have any comments or questions, I encourage you to contact me through the links at the top of the page. Thanks for reading!

Target audience

What is Infrastructure from Code (IfC)?

IfC with Ampt

Optimizing over time

Conclusion

Further reading