Honoring the past and applying the lessons towards the future of software engineering
Building and running any software or system at scale is a feat in its own right and 25 years ago we challenged that model further with the emergence of SaaS and having the public internet be the primary way to deliver those apps. Over a decade ago, Adam Wiggins (Founder of Heroku) published the Twelve-Factor App methodology as a way to codify the best practices for writing SaaS applications with contributors who all had first hand experience in building and running SaaS apps at scale. Twelve-Factor remains for many engineers as a guiding principle for how to architect apps well, manage software growth and erosion, and to take advantage of cloud platforms of the time. A lot has changed since then.
It goes without saying that “what is deployed is almost immediately tech debt and will also live forever” so how it is built, deployed, and run is critical to its ongoing success.
Evolution of software and systems
The only thing constant is change and that’s never been more true than in the past decade of technology. The introduction of containers changed our unit of deployable software resulting in a whole new ecosystem for orchestration, management, networking, security, and more. Kubernetes has emerged as the operating system of this new abstraction and the API contract between the infrastructure layer and application services maintaining a separation of concerns.
How we write software has changed.
What we need in a software delivery life cycle has changed.
How we deploy and update apps and infrastructure has changed.
What we look for in running apps and production environments have changed.
With all that has changed, we find ourselves asking questions on how to solve today’s problems and what lessons from the past are still durable?
Truth in Factors
At Heroku, we were designed as an implementation of the Twelve-Factors to give developers a platform experience with the best possible outcome. Fast forward to today, we find ourselves reflecting on these principles while considering all of the innovations and shifts in our industry around containers, Kubernetes, cloud, open source, and what that could mean for the Twelve-Factors and Heroku.
When looking ahead and the changes required to embrace the future, it’s important to honor the past as knowledge to help inform the new strategy. Reviewing the Twelve-Factors showed us that the factors themselves are durable as core concepts for today’s landscape and relevant as we look towards what the apps of the future could look like.
The Twelve-Factors
- Codebase: One codebase tracked in revision control, many deploys
- Dependencies: Explicitly declare and isolate dependencies
- Config: Store config in the environment
- Backing Services: Treat backing services as attached resources
- Build, release, run: Strictly separate build and run stages
- Processes: Execute the apps one or more stateless processes
- Port binding: Export services via port binding
- Concurrency: Scale out via the process model
- Disposability: Maximize Robustness with fast startup and graceful shutdown
- Dev/prod parity: Keep development, stating, and production as similar as possible
- Logs: Treat logs as event streams
- Admin processes: Run admin / management tasks as one-off processes
These factors are still at the center of many discussions within technology teams. The content of those discussions on the practices the teams are looking to implement are quite different from the discussions of a decade ago. Taking into account the changes in technologies available, we are able to have new conversations about how best to put logs, configs, or concurrency into practice.
Factoring in the Future
To advance its purpose and expand the discussion, we want to invite the community to join in. The universe of applications has grown beyond the first set of web apps the manifesto was initially written for. New deployable units like WebAssembly have entered and the various flavors of Artificial Intelligence are a couple of examples of technology change yet to be fully considered in the scope of application and systems architecture or best practices.
If the only thing constant is change, then we must also continuously review the factors, revise as needed, and consider changes that take in the collective learnings from the community to formulate guidance and best practices for the rest of the industry.
To learn more about Kubernetes and the cloud native ecosystem, join us at KubeCon + CloudNativeCon North America, in Salt Lake City, Utah, on November 12-15, 2024.
##
ABOUT THE AUTHOR
Betty Junod, Heroku CMO
Betty Junod is the CMO and SVP of Heroku, a salesforce company. Heroku is a Platform as a Service (PaaS) provider enabling organizations to accelerate the development and secure delivery of cloud-native applications. Betty has previously held marketing leadership postitions at VMware, Docker, solo.io and is a strategic advisor to technology startups. She likes to hang out at the intersection of enterprise software, open source, and developer tools and enjoys a good selfie with the community.
