Get in touch
In this three-part blog series, we aim to introduce you to Flamingo, the modular open-source framework from AOE, which is based on Go. If you missed the first part about the Go programming language or the second part about development frameworks, you can catch up on both articles here at any time. In today’s third and final part, we’ll focus on Flamingo, AOE’s fast application framework with plug-in functionality.
Look forward to Part 3: Introduction to Flamingo
In real-world technology environments, there’s rarely a one-size-fits-all tool or standard solution that fits perfectly. Suitability depends on specific requirements, constraints, the broader environment, and context. This is certainly true for Golang frameworks. Before adopting any framework, it's crucial to question what type of process optimization it was designed for and, as discussed in parts one and two, what kind of user it is intended for.
Flamingo is a Golang framework for full-stack web development within enterprises, based on the following business-critical priorities:
In an enterprise, it’s rare for an application to operate entirely in isolation. Most behave like nodes in a vast network, constantly interacting with various data stores and external services. Ultimately, the application needs to store its generated data somewhere, and this location is generally a shared database, managed by a specialized team of database enthusiasts.
However, an enterprise’s data landscape is more than just a few databases quietly exchanging information. It’s typically more like a bustling data party with guests ranging from the new kids on the block (hello, vector databases) to time-series, search functions, various SQL variants, and NoSQL, all the way to the old guard (those steadfast IBM Z-series mainframes that refuse to leave the party even though they’ve overstayed their welcome).
Moreover, the average application must juggle a variety of tasks: digesting data bites, passing notes to other applications, setting off a fireworks display of alerts, and logging as if there’s no tomorrow. Each task forces developers to figure out where to weave new functionalities into the code maze and how to align them with everything else.
Each of these decisions contributes to a growing tangle of often conflicting developer opinions. These opinions permeate every corner of the application, from the shiny user interface down to a dusty background script. And no matter how much REST, gRPC, or SOAP is used, an API is just another dependency that gets woven into the application. Within the enterprise, all these embedded opinions can quickly become overwhelming. Trying to move away from a now-uncool technology becomes a Herculean task, with developers playing hide-and-seek in the codebase, tracking down every secret reference to the outdated technology.
This is where the Flamingo framework comes in – the charming diplomat of the enterprise IT world, skillfully navigating the complex geopolitics of application architecture with its secret weapon: hexagonal architecture, or as the tech-savvy call it, Ports and Adapters. Imagine the core business logic of your application as the cool, composed ambassador stationed at the heart of a busy embassy. Surrounding our ambassador are various departments and attachés – the Ports and Adapters. These are the specialists with expertise in dealing with the outside world, whether connecting to database nations, sending dispatches over web services, or negotiating contracts with APIs. They’re the indispensable interpreters, translating the needs and responses between the core and the outside world.
With the finesse of an experienced diplomat, Flamingo ensures that the ambassador (the business logic) isn’t distracted by the complexities of external communication. Need to change your diplomatic approach to a data source or switch up your communication protocol? No problem! That’s the job of the adapters, who swap out diplomatic personnel to better suit the changing international landscape. This flexibility allows for smooth transitions and adaptability, much like a diplomatic corps adjusting to new political realities.
And to extend the diplomacy analogy a bit further, Flamingo can also serve as such for the internal development team. By providing a structured approach to organizing code and dependencies, Flamingo takes much of the decision-making and coordination off the team’s plate, replacing it with Flamingo’s proven conventions. And as anyone who’s ever had to mediate between developers on issues like logging frameworks, formatting, or testing frameworks can attest, this can save a lot of time.
Flamingo is designed to fit seamlessly into modern production environments. It’s also a framework where the batteries are included. This means applications developed with Flamingo are ready to go right out of the box. For deployment, Go compiles standalone binary applications, which are perfect for containerization. This allows modern infrastructure teams using DevOps or platform engineering approaches to easily deploy Flamingo-based applications with Docker, EKS, or tools like Fargate.
In production, Flamingo applications typically have a lower resource footprint. Since Flamingo is a Golang binary rather than an interpreted language, Flamingo applications require fewer resources than their Python or Java counterparts. Additionally, they’re better equipped to leverage modern multi-core systems, making the latest cloud resources more cost-effective. To simplify monitoring, Flamingo has OpenTelemetry integrated, enabling developers to quickly and easily add application telemetry. For platform engineers or operations teams, this also simplifies monitoring and tracking, meaning system logs and metrics are easily found and consistently implemented across all Flamingo apps. Business metrics for analytics are likewise intuitive and consistent.
But what does all this mean for the beleaguered application architects and developers, who often have a large heap of requirements dropped on their plate without the appropriate glass of time to help wash it down?
Simply put, Flamingo is both an accelerator and force multiplier. It allows solutions to be spun up quickly while allowing developers to become proficient in a short period of time. As an architect, it allows you to choose the most appropriate points of connection within an application, selecting the modules that make sense and fit within the client’s technology stack. It also lets you describe how those modules map into the business logic that the developers will work on.
For developers, it means leaving behind the dreary land of endless code-plumbing and enter the sunlit uplands of abstracted business logic. With Flamingo, more tedious elements such as logging, metrics, and alerting are all concerns of a higher part of the stack and can be largely ignored once implemented. This also means that if the architect finds that they have to swap out one of those modules, either due to unclear requirements, or something shiner coming along, they can do so without disrupting the ongoing delivery of features.
The beauty of abstraction in Flamingo extends to the reliability of the application. The framework is similar to having a well-organised filing system where everything is in its rightful place. Testing becomes a breeze – or at least less of a gale-force wind. With the code is neatly compartmentalised, business logic testing becomes a focused task without worrying about the nuts and bolts in other layers.
Flamingo draws on the inherent syntactic simplicity and benefits that Golang itself brings. This offers two significant advantages: First, the learning curve for developers coming from languages like PHP or Ruby is both quick and gentle. The second, related advantage is that in an organization where these languages may have been used for decades, existing internal developers can be easily integrated into a project written with Flamingo. Often, these long-time internal developers best understand how the business logic in a particular application is coded and why. This is exactly the kind of tribal knowledge that’s easily lost when established developers feel pushed out by new requirements to learn a tedious new language that’s just come into fashion.
Additionally, Flamingo’s design philosophy marries a strong, user-friendly language with a preference for conventions and configuration over direct coding. Many of these features can be implemented with a snippet of YAML or CUE, challenging the traditional dogma that pure coding is at the pinnacle of software development. Flamingo takes a more pragmatic stance here. It champions the idea that code directly addressing business problems should be front and center; everything else, though necessary, is secondary and better managed through conventions, configuration, or within the Ports and Adapters model.
By relying on Ports and Adapters architecture combined with the power of Go, Flamingo makes it easy to create “tactical” solutions. Some users, after being introduced to Flamingo on a Friday, were productive by Monday, having written working microservices after spending the weekend getting familiar with the software. Promoting modular reuse and maintaining clean and appropriately abstracted code facilitates rapid iteration, the holy grail for any technology provider.
Flamingo offers numerous undeniable advantages. However, in this blog, we’re not claiming that Flamingo is the best solution for you and your company. Rather, we aim to show you where and why this might be the case.
Curious? Want more information about Flamingo or to test our framework yourself? Feel free to reach out to our AOE development team through this link.
