The most common questions I get from customers – whether it be developers or executives – are targeted at understanding how Amazon is able to move so quickly. They want to know about our company culture, our organizational structure, the internal tools we use, and the type of people we hire, just to name a few. Of course, there’s no single answer here. Further, what might be a challenge at one company isn’t necessarily the same at another. But there’s one thing I’ve found that’s as close to a silver bullet as you can get – Developers. More specifically, it’s about hiring the right kinds of developers and then empowering them to do what they do best – build.

Interestingly, this empowerment aspect is where a lot of companies struggle. Sometimes, a company’s organizational structures or internal policies act as barriers to letting developers build, and there are non-technical levers that can help a company move more quickly. But sometimes, the problems are more tied to the actual technologies themselves, and how these are rolled out and managed across the company. Building in the cloud is an obvious first step here, as it allows companies to experiment and deliver faster than they can on-premises. In the cloud, developers have the ability to use the best technology for whatever solution they may be building and can easily deploy a web-scale solution in fractions of the time they can elsewhere. But like the answer to the original question, on its own the cloud is not always a silver bullet. When companies try and apply the same traditional thinking they use for on-premises infrastructure to evaluate, deploy and operate applications in the cloud, they still may not be able to run at the speed they want to. So what needs to change?

Today, I want to share more about our thinking at Amazon, and how our developers, modern application development and platforms are at the center of our ability to move fast. If you want to run faster as a company, let your developers serve themselves. Let them innovate without having to ask for permission. Use guardrails and platforms that enable developers to focus on the more valuable part of their jobs. Abstract away unneeded complexity, but give them choices that are relevant to them.

An expert-curated cloud

We introduced AWS Proton last year at re:Invent with the goal of doing just that – let developers build, help companies move faster, and bring consistency to your AWS architectures. I’m delighted to announce that today, AWS Proton is Generally Available.

AWS Proton is a fully managed application deployment tool focused on empowering experts to standardize, observe and manage the deployment of applications within their organizations.

The goal of AWS Proton is simple: customers should be able to adopt, customize and evolve best practices and technologies for delivering their modern applications to the cloud, and not worry about how they roll this out – potentially to thousands of developers – across their organization. Experts need to be able select the best cloud resources, deployment tools and delivery mechanisms for the business, with the confidence that they will be adopted within the organization efficiently and without slowing down developers.

Modern application development

At AWS, we often talk about modern applications, and AWS Proton is a game changer when it comes to developing truly modern apps. At the core, modern application development means leveraging technologies and delivery paradigms that allow developers to move fast and be unencumbered. For instance, breaking a monolith into microservices allows teams to move fast and operate independently of each other; using containers and serverless gives developers maximum portability and the capacity to right-size their resources to the needs of their application; observability guarantees that any performance changes in the microservices and application will be noticed early; and continuous integration and continuous delivery reduces the size and complexity of deployments, so that new features can be released to customers faster and with lower risk.

Proton allows customers to adopt and optimize these aspects of application development – microservices, containers and serverless, observability and CI/CD – by empowering customers to choose the right technologies, tools and processes and rolling them out across their organization. It does this by focusing on three areas: collaboration, self-deployments, and evolution.

Collaboration: Define best practices, together

Our vision is that experts describe the best technologies in a template, and this template is a living, public object that can evolve over time, whether it comes from experts creating new versions or stakeholders suggesting updates. At the same time, developers can customize this template at the time of deployment. Having a public repository of Proton templates allows your stakeholders to understand your technology choices and work together in making them better. Experts still curate the final options and make them available, but knowledge is not restricted and enhancements can be owned by all.

Proton embraces collaboration in templates. Templates in Proton can be customized and evolved in multiple ways. Today, Proton allows platform teams to define new versions of existing templates and roll them out to existing services without requiring developer intervention. Over time, we will be expanding the surface area of this collaboration. For instance, you will be able to sync your templates from a Git repository, so any stakeholder can suggest an improvement with just a Pull Request. Developers will also be able to add custom infrastructure to their services at the time of deployment so that they can include the resources they need, and experts will be able to validate these one-off changes before they go live. If you want to stay tuned to what features we are launching in AWS Proton or request your own, I recommend you follow the public roadmap in GitHub.

Self-service management: Deliver your application on your terms

Defining a secure, easy-to-use template for application delivery does not slow down a development team: it speeds them up. They can focus on their code knowing that delivering it to the cloud is fast and easy. But if accessing this template requires going through convoluted processes, cutting tickets, and waiting for approvals, then the value is lost. We need a mechanism that allows developers to access the infrastructure they need, in a fully self-service manner, while maintaining the visibility and control in the hands of the experts

Proton does this by offering a fully self-service interface to deliver an application. From the Proton UX, developers can see the templates available and choose one to use, including providing the required parameters. They can also see the deployment status of their services and make changes to them, such as updating parameters or deploying them to new environments. Moving forward, we plan to continue incorporating functionality, for instance enabling developers to trigger rollbacks directly from Proton or displaying the health status of the services, based on their underlying observability tools, in the Proton console.

Evolve together: Bring your applications up to your newest standards

Of course, ever-evolving templates are only useful if you can move your existing deployment with them and change not only your future practices, but also existing ones. Infrastructure-as-code tools allow you to create and share templates, but they are a snapshot in time of your architectural choices, and they don’t provide an avenue to update your deployments. As new tools and resources become available or as the requirements of your business change, you probably want to revisit the choices you made when you created the template, and you don’t want to feel like a decision that you made six months ago is now unmovable.

This is a core tenet of AWS Proton: supporting applications throughout their lifetime. Customers can use AWS Proton to see what has been deployed, and by whom. They can keep track of which version of the underlying AWS Proton template is in use by each microservice, and bring it up to the latest version with one click. This is done transparently to developers, who do not need to be involved, as Proton is responsible for injecting their deployment parameters to the new template version.

Define your infrastructure

Now of course, everything comes with a cost. In the case of Proton, that cost is the process of defining the infrastructure and making it available through Proton. To truly embrace these modern paradigms, you will need to make them your own – define your serverless and containers infrastructure; configure your CI/CD pipelines; select an observability strategy – then go to Proton, set everything up, and start the process of adopting in your organization. This work pays off quickly; the outcome is a highly streamlined experience for developers and an organization that is able to ship modern applications efficiently and securely at scale.

Supercharging application delivery

The world of digital technologies is moving faster than ever, beyond what individuals or even individual teams can keep up with. Like our thousands of internal technology teams at Amazon, our customers have the same challenges and need to be confidant that, across all their distributed microservices, they’re meeting their security, compliance and cost standards.

As I stated at the beginning, I believe that the solution to complexity and speed is not to remove the choice of using the right technology for the right job, but instead to give developers the ability to choose what matters to them, removing the unneeded fudge, and help them use it efficiently. Similar to an orchestra using related sheets of notes to produce beautiful music, companies can move more fluidly, and more quickly, through the use of frameworks.

I’ve seen many attempts at finding this harmony. We can outsource our infrastructure to a third-party Platform-as-a-Service (PaaS), which provides a single interface that includes all components of the application delivery, but this takes away choices from experts in our organization, who have to accept the decisions made by the creator of the PaaS. Alternatively, we can require a specific group within our organization to be responsible for deploying and managing our applications, but this introduces a new bottleneck for our delivery and creates a barrier between developers and the technologies they need. Yet another option is to create our own delivery platform: an internal tool that allows developers to deliver their application using approved infrastructure. Of course, this means that we have to design, create and maintain such a tool, which is by no means trivial. And even further, we have to continuously adapt it to our changing needs and new technologies.

Our goal is to remove undifferentiated heavy lifting for our customers. Supercharge your application delivery by allowing your infrastructure experts to unblock your developers so they can focus on what matters: creating amazing applications using the best technologies available.

To learn more about supercharging your application delivery, see AWS Proton.