Having been a software developer for quite some time now, I've had my fair share of "experiences." The thing is, most of them were just piecing together things instead of writing actual code that solves a business problem. As Stephen O'Grady, co-founder of Redmonk, succinctly put it, "...developers are forced to borrow time from writing code and redirect it towards managing the issues associated with highly complex, multi-factor developer toolchains held together in places by duct tape and baling wire."

I came of age as a developer around the time that frameworks like Ruby on Rails appeared (I did not use Rails since I did my coding in PHP at the time, most of it with the CakePHP framework). Rails inspired many other frameworks for other programming languages that followed its opinionated approach (how about that "MVC craze" in the mid-aughts?). What was empowering about Rails and similar frameworks, though, was that it took care of many things that distracted developers from solving the actual business problem, such as connecting to databases, configuring routes, and so forth. That led to many innovative ideas coming to market faster and shortening the feedback loop. Many went on to become multi-million-dollar businesses and services (GitHub, Airbnb, and Shopify are the poster children for being built on top of Rails). Rails and its clones did this by using their opinionated approach and convention over configuration or, as Bryan Liles describes it in his KubeCon keynote, by being good at providing suitable defaults.

Quite a few years have passed since Rails and similar tools appeared. We now live in a world of public clouds, with many available services that cater to many developer needs. But despite the availability of many tools and solutions, we're still having to put an overwhelming number of things together before writing a single line of business code (and then manage all of it once it's up and running in a production environment). "When you use a tool, it should be easy to use. It should just seamlessly drop into your workflow and elevate you," says Taylor Dolezal, a Developer Advocate at HashiCorp.

All of which begs the question, can we do something to make developing cloud-native applications a joy and not a hassle?

At The Agile Monkeys, we've become aware of those hassles, especially after years of work consulting for many different organizations of many different sizes. Our experiences led to the creation of Booster. Booster is a tool to improve the development experience for those who want to focus their attention on writing actual code that solves a real business problem instead of tacking together cloud infrastructure through multiple configuration files that they then have to integrate into many different configuration management tools.

Booster is a framework for developing software, much like Rails, but it is made for the cloud-native times we live in today. You install the Booster CLI, scaffold and generate boilerplate code, implement your business logic following its opinionated approach, configure your cloud provider, and you're ready to deploy in a cloud-native fashion! To get a better idea, you can watch a 10-minute demo here.

Booster's main contribution to an improved developer experience is inferring everything from the business code. Just using the business code as input, Booster is able to select and provision the required cloud resources (based on your cloud provider of choice), configure the necessary connections and permissions, and return the GraphQL API endpoints, which can then be used by front-end or mobile applications to interact with your system. No more configuration via convoluted YAML files. No more provisioning via vendor-specific SDKs or consoles. The fine folks from the Booster community (be sure to reach out to them on Discord!) have taken the trouble of doing that so devs don't have to.

I believe the future of cloud-native application development is in tools like Booster, tools that will support better development workflows and a more enjoyable developer experience. I recently read this article with the title "Developer experience is the next major competitive front in enterprise tech," and you know what? I could not agree more.