Ampt is now available!

For everyone that's been waiting to get their hands on Ampt, the wait is finally over. Ampt is officially available to the public! Six months ago, we announced our private beta and the journey since then has been truly transformative. With hundreds of developers providing invaluable insights and feedback, our roadmap has been significantly shaped by the experience and needs of our beta testers and design partners. The platform has come a long way and we believe it represents a major step forward for cloud development.

Why Are We Building Ampt?

Whether you're an expert struggling to implement efficient workflows across distributed cloud systems, a developer wasting time on slow feedback loops and long deployment cycles, or just someone constantly obstructed by steep learning curves, you're sure to find the cloud full of frustrations. It shouldn't have to be this way.

At Ampt, we've reimagined the cloud development experience from the ground up and created a simpler, more intuitive way for developers to build native cloud applications. Using a radically different approach that we call Infrastructure FROM Code, developers literally just write their application code and Ampt automatically infers the necessary infrastructure and configuration requirements. No need to get bogged down with infrastructure provisioning, complex cloud configurations, CI/CD, secrets management, security controls, or other operational burdens that prevent you from shipping software. In fact, Ampt reduces operational complexity by up to 95%, empowering teams to concentrate on delivering value to their customers while letting us handle the undifferentiated heavy lifting.

How do we do this?

A radically different approach to cloud development requires a completely new way of thinking about how cloud infrastructure is provisioned, resources are configured, and applications are deployed. For context, let's review the most common cloud development processes.

Traditional Infrastructure As Code (IaC) solutions such as Terraform, CloudFormation, and even the AWS CDK, are not only overly complex and require deep knowledge of the cloud primitives being used, but they also produce static representations of your infrastructure graph. This means that modern applications, which rely heavily on the underlying cloud resources, must utilize coordinated infrastructure mutations and code deployments to support new software delivery. Advanced cloud teams are generally able to automate these complex systems, but the vast majority of teams end up creating brittle CI/CD pipelines, or more likely, none at all.

Serverless architectures have been a step in the right direction by coupling the deployment of application code and infrastructure configuration together. This dramatically reduces the coordination problem. However, serverless also shifted a tremendous amount of responsibility onto the application developer. Besides just business logic, serverless "developers" are now responsible for the infrastructure and cloud architecture, build and deployment pipelines, monitoring and observability, and application security and compliance. In addition, serverless applications rely heavily on programmable cloud services for implementing state machines, data transformation pipelines, and other workflows that are embedded in your infrastructure graph. While highly performant, this creates a bifurcation of business logic akin to "Stored Procedures", obfuscating business processes and making applications harder to reason about and even more difficult to debug.

Another common approach is for organizations to use a platform-as-a-service (PaaS) that typically runs on top of the public cloud providers. There are many excellent PaaS offerings out there that provide cloud hosting solutions out of the box. However, these platforms are often highly opinionated and optimized for only a few specific use cases. This not only limits a developer's flexibility but, in many cases, comes with inherent scaling limitations due to the platform's design. The "graduation problem", while likely a positive sign of growth, generally requires a painful migration process directly to a public cloud provider.

The final approach, known as platform engineering, has become increasingly popular as of late. While technically not a new term, it has come to refer to platforms and services that allow operations teams to configure templates, pipelines, and security guardrails that give developers within their organization the ability to deploy applications within these constraints. These platforms, whether off the shelf or built in-house, require operational expertise and significant investment to implement.

Each of these approaches comes with significant benefits but, as with all things, also have several tradeoffs. Balancing control, flexibility, operational complexity, developer experience, and security, on top of managing skill gaps on your teams, is an arduous task that can take years for an organization to eventually find what works for them. We knew we were unlikely to change your team's culture, but we certainly believed that we could dramatically reduce this balancing act.

Our primary goal was to make sure teams could leverage native cloud services directly. This would allow organizations to take full advantage of the cloud's reliability, elasticity, scalability, and resiliency without imposing extra layers of abstraction that could compromise performance. There are hundreds of well-architected patterns that have been developed, battle tested, and perfected over the years, but the challenge was to figure out how to let developers implement these patterns without necessarily being a cloud expert.

The first step was to design an interface that allowed developers to express use cases and business logic without worrying about the cloud infrastructure it would run on. We didn't want to create a new language that gave developers something new to learn, or require a specialized IDE which would force yet another tool into an already complex workflow. As developers ourselves, we wanted something that was fast, familiar, and easy to use. This led us to adopting a standard JavaScript SDK approach that exposes a series of "interfaces" to the application. These interfaces allow developers to define "handlers" (i.e. functions or subroutines) that are triggered by certain actions in the system like events, data changes, http requests, etc. For any developer that's used Express.js or a similar library, this will be as familiar as writing a route handler or piece of middleware. And since this interface is just regular JavaScript, the entire Node.js ecosystem is available to use.

With the use cases and workflows defined, the next step was to translate them into the appropriate patterns and deploy them to the cloud. Using a process we call "Runtime Introspection", Ampt parses your code and identifies the resources and configurations needed to run your application most efficiently. Now here's the really cool part. The Ampt service pre-provisions isolated cloud environments to allow for insanely fast deployments. These environments use Ampt's self-provisioning runtime to automatically configure the environments to support your application, and it only takes a few seconds to do it.

With the Infrastructure FROM Code approach, your business logic is your only focus. Ampt infers the necessary infrastructure, optimizes it for performance and cost, and manages the deployment lifecycles for you. Developers stay in control of their workflows, while Ampt manages the cloud environment. For enterprise customers that require additional control and insight, we also support deployments directly to customer-owned AWS accounts.

And there's one more thing. Since this process is fully integrated from the code to the cloud environment, Ampt provides developers with their own isolated, high-fidelity sandboxes with production parity. Plus, we've developed a fast syncing technology that instantly uploads and deploys code and infrastructure changes from your local IDE to your sandbox. This gives you real time testing and debugging capabilities without needing to worry about local emulation ever again.

Who are our users?

​​Ampt was initially developed with the vast and dynamic JavaScript/TypeScript ecosystem in mind, recognizing both its popularity and approachability. We believed our primary audience would be developers who were unfamiliar with complex cloud infrastructure and therefore benefit most from our streamlined development processes. However, we discovered that seasoned cloud experts—those who have built numerous applications using traditional methods—found immense value in Ampt. They recognize and appreciate the ease and efficiency Ampt brings, eliminating the need to deal with the undifferentiated heavy lifting of cloud development and management. The convenience of Ampt allows them to side-step the tedious and cumbersome parts of delivering applications to the cloud.

Another consistent theme that has emerged from our interactions with users is the desire for accelerated delivery. Startups and software development agencies, who form a significant portion of our user base, all aim for faster time to market. These organizations chose Ampt because they trust us to handle the complexities of the cloud, enabling them to concentrate solely on creating and delivering exceptional value to their customers.

Reynaldo Reyna from Sight Consulting captured this sentiment perfectly, "With Ampt, onboarding new engineers to a project, which once took a week, can now be completed in under an hour." This efficiency is a game-changer for many, emphasizing our platform's unmatched developer experience.

What's left to realize the vision?

While Ampt has already achieved many use cases, our journey has only just begun. We're dedicated to realizing our vision of simplifying cloud application development to its fullest extent.

We plan to expand our capabilities even further through partnerships and integrations. We have an upcoming integration with Momento that will let developers automatically create caches for each Ampt environment, enforcing our powerful isolation model. We also have planned integrations with database providers like PlanetScale, Neon, Xata, MongoDB, and more. We're also working on integrations with a number of observability vendors like Datadog to automatically instrument applications and environments, enhancing observability for those looking to use these best-in-class products.

We're also heavily investing in Ampt's platform capabilities. While the roadmap is certainly too long to fully cover here, some key upcoming enhancements include sync/async inter-app communications, configurable event ordering, and advanced retry mechanisms. These are critical features that will drive application resilience and performance. In addition, we're strengthening our access management features, introducing more nuanced roles, and implementing audit trails to give users a clear record of system changes. We're also working towards introducing a control plane API to let organizations programmatically manage apps and environments. We have several customers that use Ampt to deliver solutions to their customers, and this will allow them to achieve even greater efficiency by building additional automation.

Wrapping Up

This launch marks a major milestone for everyone at Ampt and we believe represents a major step forward for cloud application development. If you missed our livestream featuring industry expert interviews, demos, and a Q&A session, be sure to catch it here.

Be sure to sign up now on ampt.dev, join our growing community on Discord, and follow our journey on Twitter and LinkedIn. We look forward to your feedback. Let's create the future of cloud applications together!