196 karma · joined July 5, 2019
[0] https://infrastructurefromcode.com/ [1] https://klo.dev/state-of-infrastructure-from-code-2023/
The post covers:
- 4 primary infrastructure org models
- Reasons companies consolidate into centralized platform teams or decompose them
- Tradeoffs, failure modes and pitfalls when reorg-ing infrastructure
- A new approach porposal for leveraging cloud intelligence to empower developers
Rather than continually rearranging org boundaries and responsibilities, I argue that we need to shift the focus to tools that bring the benefits of platform orgs into infrastructure orgs.
Would love to hear what you think! What infrastructure org structures have you seen succeed or struggle?
Read the full post here: https://www.alashiban.com/you-may-not-need-that-costly-time-...
[0] https://klo.dev
"The primary reason to introduce a new example is when the LLM is incorrectly identifying technology as ABSTRACT vs not, missing connections, or even missing resources entirely. However, we don’t have unlimited tokens for every example we might need. An optimization we came up with here is Dynamic Examples using pre-filtering. Instead of providing examples that would generalize to everything, we focus the examples on what we can guess is in the queries.
We extract a list of technologies using word lists, which is easier than extracting their intents, and if we don’t find many matches, we assume that more ABSTRACT resources are present. Once extracted, we can then create a custom prompt by selecting specific examples to the technologies mentioned in the query and a set of bedrock examples including baseline rules for the different actions that expand language understanding."
Right now the architectural patterns are curated, but algorithmically tested. The next phase is to combine curation with patterns from the community.
This is open source to a large degree, it's powered by the Klotho engine ( https://github.com/KlothoPlatform/klotho )
InfraCopilot is more akin to Wolfram Alpha, in the sense that it has an intelligence/understanding of architecture. You can use high level design to describe your intent and requirements/constraints, and it will deterministically implement it (this isn't LLMs or ChatGPT). When you attempt low level changes, it will validate that they maintain correctness, because it has an understanding of impacts.
When you reshape elements, it has the understanding of follow-on effects, and how to propagate them into the rest of the architecture, all while staying valid.
[0] https://aws.amazon.com/application-composer/
It gets significantly more challenging when you grow, either in feature complexity or scale complexity - and then very few services can offer what AWS/GCP/Azure offer - albeit at the increased engineering/monetary cost of using them.
We're building a different kind of approach[0] that aims to absorb the mechanical cost of using public cloud capabilities (that are proven to scale) without hiding it altogether.
We're building klotho[0] for many of the reasons mentioned here. (happy to answer questions). We transform plain code to cloud native code. The majority of the complexity is moved into the Klotho compiler, and what devs handle is the simplest bundle that's easy to deploy and operate on public clouds using standard tools.
I wrote a more in-depth blog post about it[4]
[0] https://github.com/upscayl/upscayl [1] https://github.com/tesseract-ocr/tesseract [2] https://www.algolia.com/ [3] https://github.com/KlothoPlatform/klotho [4] https://www.alashiban.com/search-the-deck/