I once used some software online
That kept all my lambdas aligned.
Thus turning topology
Into scriptology
And leaving me hours to dine
Is it the best limerick you’ve ever read? Certainly not. But it is a poem that took me far less time to write than I would have spent if you had told me to “write a poem about scripting serverless architecture”.
It’s easy to think of constraints and rules as something that makes it harder to do work or somehow limits what we can do, but that’s not always true. Sometimes constraints make it easier to be creative and generate new ideas, precisely because you aren’t trying to think of and sort through every possibility.
It’s also easy to think of having policies and configuration restrictions preset on your architecture as a limitation, but it’s actually a huge savings of time and mental effort. Someone in your organization has already made the decision about a huge number of things, and you don’t have to think about it. There are literally thousands of policies that you could set for AWS alone, and certainly a large number unique to your organization.
The act of development is already such an enormous sequence of decisions that it helps to offload as many as possible. “What kind of pizza do you want?” is much easier than “Where do you want to go to dinner?”.
At StackGen, we know that “shift-left”, while it has a lot of advantages, also means that developers are doing a lot of things that used to belong to specialized teams. Integration tests? That used to be QA. Documentation? There was a writer for that. There were teams for security, and sysadmins, and teams for deployment. Now a developer has a much more accurate idea of what their code does and how it performs, but they have a lot more job responsibilities.
We want to help the whole team by making it fast and easy to generate Infrastructure as Code from the code that you’ve already written. If you need to have a database and an AWS Lambda to run and test the code, StackGen can read that in your code and write the structure to create it. When we write it, all of those policies and safety rails will be baked in. Then you can stand up the environment that the code needs and nothing it doesn’t need. This saves the developers time and the organization money.
Making developers more independent about creating their environments frees them from having to learn to write IaC in addition to their other duties. Creating constraints by setting policies and adding guardrails allows them to be creative and feel safe while doing it. We don’t need everyone to know everything, and we don’t need everyone to write Icelandic sagas - we can allocate the work to the places it makes sense, and let the rest happen “by magic”.
We want to free you to spend your time on questions only you can really answer, like “What is the business logic I want to use here?” and “Does anything else rhyme with Python?”.
