Updated on August 19, 2023.
In the ever-shifting landscapes of Cloud Computing, a transformative shift appears to be on the horizon.
In a previous issue, I reflected on the challenges posed by traditional DevOps practices for the Cloud: on how its rigorous nature and tooling were limiting broad adoption of Cloud and technology in our organizations; before dropping the idea of a new perspective: one that would seek to not only reduce the burden of effort required from engineers, to build and maintain applications; but also place “Business Value” back at the heart of “Operations,” ushering in an era of greater collaboration and agility. My take on “ClickOps 2.0.”
In this upcoming case of “business agility versus operational excellence," one contender stands at a crossroads, uncertain of its role in the unfolding narrative: The venerable AWS Management Console.
Over the past decade, the Console has acquired quite the reputation amongst AWS power users: Using it extensively is still often mocked by many, portrayed as an error-prone and time-consuming process, with depictions of tireless individuals clicking through endless menu options in a desperate race to deploy their Cloud infrastructure on time. A mysterious “place that sends you mad,” a challenge for those who dare to venture, casting doubt on its efficiency for business operations. Its fate long seemed sealed and its days numbered, as CLI tools and infrastructure code swiftly took center stage of common Cloud architecture.
As I started my journey in using AWS, I heard countless warnings echoing from many Cloud practitioners: “Avoid, much like ancient sirens, the AWS Management Console at all costs.”
But be rest assured that, during my time, I’ve seen even the most faithful infrastructure code devotees succumb to the lures of the Console once in a while, albeit each for their very own reasons, or sweet spots: Whether that was configuring and validating ACM certificates by hand, because, quote, “the validation process, for certificates, of our authoritative name server does not pair well with the execution of the CI/CD pipeline,” unquote; provisioning untracked EC2 instances for one-off tasks; manually scaling resource concurrency for production Lambdas functions, or manually managing IAM and Organizations permissions — some of our habits tend to persist and always seem to end up defying the constraints of our code-driven workflows.
The main reason for that, to me, is that “real-life Cloud engineering” is inherently not a code-driven process. It is instead an intricate dance between convenience and precision, a balance between hands-on engagement and automation. Much like the desired paths that naturally form in public parks as pedestrians seek the shortest and most convenient routes, your journey as a Cloud evangelist should then parallel that of a wise park manager: Rather than outrightly obstructing your teams’ inclinations to use technology as they see fit; you should strive to understand and integrate them into the official design; build frameworks that accommodate users’ desires; recognize the value of human intuition, innovation, and creativity, while upholding best practices and security boundaries.
Doing so would shift your focus to more value-added work than maintaining infrastructure code: enhancing security, optimizing infrastructure, and ensuring smooth operations. Business owners, in the meantime, would benefit from increased efficiency and reduced implementation time, allowing them to iterate and innovate faster. A symbiotic relationship where the strengths of each group are leveraged, fostering collaboration and driving success in the Cloud ecosystem.
A place and time where the AWS Management Console would be here to provide a visual and intuitive way for all to interact with complex systems; that you build and maintain.
If you’ve ever dismissed the use, to your users, of the Management Console; you’re not alone, and I understand your reasons. The Console has faced its share of challenges due to… contrasting design choices made in the past, that could’ve left newcomers feeling overwhelmed. However, you should not underestimate the tenacity of dedicated teams at Amazon, that have tirelessly been breathing new life into this interface since 2016.
The Console has much evolved, and this transformation has been nothing short of captivating to me. Some services, many underutilized, found a well-deserved and much-needed second youth with the adoption of Amazon’s innovative Cloudscape Design System. Of course, like any significant modification, voices of dissent echoed among the crew: Drastic UI changes are always disconcerting, especially when said UI helps you deal with hot fixes for million-dollar production workloads. Nevertheless, despite the grumblings and initial hiccups, it seems to me that AWS has charted the right course for this interface, this time:
In quite a bold and unexpected move, the entire Cloudscape Design System was open-sourced earlier in 2022. A gesture that will hopefully foster a stronger long-term collaboration between the AWS product team and us, the customers. A decision that could ignite a spark of inspiration for greater flexibility and customization, empower Cloud practitioners and stakeholders to craft tailored experiences that perfectly align with their business and Cloud platforming needs. Possibly even transcend the Management Console in its entirety.
Do also consider that some of the most recent innovations from Amazon, like Application Composer which I previously discussed, all aim to put interfaces back into our workflows: Services such as AppFlow or EventBridge Pipes also gained considerable momentum recently, as organizations strive to reduce the costs associated with operating ingestion & data pipelines.
AppFlow offers a standardized and intuitive approach, allowing seamless ingestion of third-party data directly into your analytics environment from the Console itself. This eliminates the need for complex data pipelines or intricate semi-structured data lakes, delivering immediate value and insights to your business.
EventBridge Pipes, meanwhile, empowers users to configure point-to-point data integrations between services, both within AWS and beyond, using a well-defined and visually appealing interface. The streamlined process minimizes the margin for error, ensuring smooth and efficient data transfers.
What is common about both, is that their user-friendly experience seemed to have been prioritized over maneuverability in infrastructure code. This, to me, is a public example of the intrinsic power of the Management Console, demonstrating the tangible benefits of embracing ClickOps in our Cloud ecosystems. As we witness these transformations, it becomes evident that the Console could evolve into an even more invaluable asset for organizations seeking optimal business efficiency and agility.
This announces a paradigm shift towards user-centric design that I believe is for the better: In the past, I found myself contemplating architectural decisions within the sole confines of YAML files too many times, treating the CloudFormation documentation as my sacred scriptures. I unwittingly allowed the complexities of deployment—and seemingly trivial criteria such as the verbosity of underlying infrastructure code—to dictate my design choices; almost as if I was blindly following a GPS into a treacherous riverbed—an adventure in itself surely, but not necessarily the wisest route.
A perfect example of this was my inital dismissal of building state machines with Step Functions, as I had concerns about the maintenance challenges of managing such workflows in infrastructure code. If you’ve ever dabbled with CloudFormation for such tasks, you probably know what I mean: configuring these feels daunting, basically maneuvering infrastructure code nested within infrastructure code.
The idea of relying on these structures to define my workflows seemed daunting and error-prone, leading me to question their potential benefits compared to developing and managing my own custom, fully decoupled, event-driven Lambda orchestrators: Using a combination of EventBridge rules, SQS queues, and Lambda Event Source Mappings sure made for great infrastructure diagrams, and offered me greater control and flexibility
(over my YAML definitions).
I cannot help but wonder if I had prematurely discarded the value
that Step Functions could bring to my architectures. It was like setting aside an enigmatic puzzle without fully exploring its potential. To my astonishment, I much later discovered that building Step Functions through its new
—Something I had surprisingly never tried before—was nothing but revigorating. It felt intuitive and efficient, sparing me the headaches of navigating treacherous code.
With this new era of serverless, and array of services; I envision a framework that transcends the boundaries of technical expertise. A realm where even non-technical individuals can embark on the exciting journey of Cloud experimentation with some newfound ease. Tasks that once demanded hours of trial and error in infrastructure coding can now be accomplished with a simple click of a button, inspiring curiosity and paving the way for navigating the vast and ever-growing AWS ecosystem.
Dear AWS Management Console,
As the Cloud landscape continues to evolve, I have a heartfelt wish for you. Be built for purpose. A true enabler for all, including those new to the journey. Provide extended customization options that allow us, builders, to mold and shape your interfaces to fit our unique needs. Unleash fresh and innovative ways to interact with our applications, making Cloud engineering an exciting and enriching experience.
In this grand adventure of Cloud Computing, be the guiding star that helps onboard non-technical profiles with ease. Make them feel at home in the Cloud, empowering them to explore and contribute to the digital landscape.
A Cloud Builder