One of the key things I hoped to leave with was the ability to articulate the value of Local Measure joining the Zendesk team. For context: Local Measure built Engage for Amazon Connect - a full CCaaS layer on top of Connect - and their acquisition brings that native channel depth directly into the Zendesk ecosystem. With Zendesk Contact Center, the impact is evident.

Some of the key takeaways for me were around the current market landscape for Amazon Connect in the Contact Center. These included:

1. “Overlays are dying”: The overlay model isn’t the future. What’s an overlay? A custom CCP built on the Amazon Connect Streams SDK - essentially a feature-extended agent softphone that sits on top of the connect CCP (figuratively). These made a lot of sense pre-Amazon Connect Agent Workspaces, especially for customers without a CRM that natively embedded the Amazon Connect CCP and needed added functionality. It’s also clear that AWS has not prioritized feature parity between the Streams SDK and Agent Workspace. CRM tie-ins make this even more evident - Zendesk’s native Amazon Connect integration and Salesforce’s ever-evolving CTI adapter, SCV and CCaaS flavors both demonstrate that the embedded CRM experience is where the market is heading, not custom-built agent desktops. This makes the overlay a situation where custom overlays are chasing a moving target, and the ROI case is getting harder to make.
2. AHT is going up, not down. This makes sense: bots are handling the easy stuff, so human agents are left with the harder, more complex calls. The metric looks worse on paper, but the workload composition has shifted. An agent’s average handle time climbing from 4 minutes to 7 minutes isn’t necessarily a problem - it might mean your containment rate jumped 40% and what’s left is genuinely hard. The challenge is that most contact center leadership is still reading AHT as a performance signal without that context.
3. Non-human-agent reporting is a gap. Specifically, trying to apply traditional call center metrics - AHT, ASA, FCR - to bot interactions doesn’t really work. A bot that “handles” a call in 45 seconds and transfers isn’t the same as a bot that fully resolves. First Contact Resolution, in particular, loses meaning when the “contact” is split across an IVA and a human. The industry doesn’t have a good answer for this yet.
4. Queue management remains a pain point. This isn’t exclusive to Amazon Connect, but it’s compounded by Connect’s expanding routing capabilities - specifically Proficiencies and Pick Lists. Proficiency-based routing lets you score agents on skills and route accordingly, which is powerful, but adds real configuration complexity when layering on top of queues, routing profiles and giving agents the ability to pick contacts out of the queue. The more granular your routing logic, the harder it is to predict queue behavior at scale and the easier it is to accidentally implement inefficiencies and create the opportunity for abuse.
5. QA’ing automation is an emerging need. As bots handle more volume, evaluating bot behavior becomes just as critical as evaluating agent behavior - arguably more so, given scale. This sounds like a reporting gap, but it extends beyond that. It’s about building rubrics for IVA interactions: Was the right intent recognized? Was the resolution path appropriate? Was the handoff clean? Most QA tooling wasn’t built for this, and most QA teams aren’t trained for it either.
6. Post go-live support is underserved - real opportunity here. Going live on a CRM is a different problem than going live on a channel that supports real-time communications. A CRM without a live channel integrated has human latency baked in - agents are switching tabs, copying notes, managing context manually. When you integrate the channel, that latency disappears and every inefficiency it was masking suddenly becomes visible. Customers often interpret this as the integration creating problems when it’s actually just exposing them. That gap in expectation management and post-launch optimization is largely unaddressed in the market.
7. Front-end for Connect admin - this circles back to the overlay concept. Do you recreate the Amazon Connect experience, or do you improve it? Increasingly, the answer has to be “improve it”, otherwise you are in a race you will never win. This requires opinionated decisions about what “better” looks like for a given customer segment, which is harder than it sounds.
8. Knowledge quality drives IVR/IVA retention rates. A referenced customer showed 80–90% containment tied directly to the quality of their knowledge base. Not the sophistication of the bot, not the model - the knowledge. This is an underrated point: you can deploy a best-in-class IVA and still get 40% containment if the underlying content is stale, incomplete, or inconsistently structured. This is what I’m calling the iron triangle of IVA (more to come on that).
9. Marketplace-style onboarding for Connect is strongly desired. The ask was simple: give me the same click-through, guided experience to get up and running on Connect that I get when signing up for Zendesk. Right now, Connect sign-up often means navigating a new AWS account, IAM, and a handful of service dependencies before you’ve even touched the product. That friction is real and it’s a barrier - especially for customers coming from simpler CCaaS backgrounds.

So the big question, in the world of Amazon Connect is: What’s AWS going to address? How does this resonate with customers? Whose going to dominate ecosystem by solving for these?

Finally, it was great seeing some old AWS friends, finally getting to meet some of the Local Measure stars, and unfortunately missing a presentation featuring a very old customer.

Or, in the words of Ludacris:

James: Shit man, I got myself a little internet business myself

Willy Beamen: Oh yeah? What’s that?

James: cocks gun Robbin’, muthafucka

Customers don’t care. Investors do. AWS does (or whoever your ‘partner’ hyperscaler is). Anthropic does (J/K they don’t care). I guess they all give you money in one way or another, some in exchange for labor, some in exchange for your soul.

This is very evident when I look at the positioning of some technology consulting companies (and no, I am not referring to a former employer). It’s a problem with the industry as a whole, and AWS did a poor job of articulating it to partners (my experience was an obsessive, not in the customer obsessed way, of consulting offers, or I mean solutions).

What do customers think? Customers don’t care (I think I said that already).

What do they want?

1) Value

Customers are fundamentally seeking value. This means they want a product or service that fulfills a genuine need, and they want it delivered in a way that either costs them less or generates more value than alternatives. For instance, if a company can automate a process that saves a client significant time and money, that’s value. It’s not about the complexity of the technology behind it, but rather the tangible benefits it brings to the customer’s bottom line.

2) Consistency

Consistency is crucial. Customers want to know they can rely on a company to show up and perform every day, no matter what. This includes being available, dependable, and delivering a high-quality service whether the team is dealing with personal challenges or not. Consistency breeds trust, and trust is the cornerstone of long-term customer relationships.

3) Safety and Performance

Customers also look for safety in their business partners. This can be demonstrated through a company’s past performance and reliability. They want assurance that the solutions they adopt won’t fail them and that their peers are working with proven, reliable technologies. Moreover, customers want to feel that they are not missing out on industry trends and best practices. This is why seeing what other successful businesses are using or avoiding can be a significant factor in their decision-making process.

4) Vision and Innovation

While not always a primary concern, some customers are drawn to a company’s vision and innovation. They might be excited about the latest technology, like the release of a new version of a software or platform, and want to leverage it to stay ahead. Conversely, other customers might feel intimidated by rapid technological changes and prefer to avoid them unless guided by an expert. For these customers, a company’s vision and ability to navigate complex technologies safely are key differentiators.

The Bottom Line

So, while touting your ability to use the latest AI technology might impress some, it doesn’t necessarily make you a hero. What truly matters is how you use that technology to deliver visionary solutions consistently, that create value and don’t expose your customers to risk. When you prevent issues before they arise and ensure your services are reliable, that’s when you build the trust and loyalty that lead to lasting business success.

Context:Title: Sticking Feathers Up Your Butt Doesn’t Make You a ChickenTags: AI Company, Customer Value, Value Creation, Customer Loyalty, Consistency, Safety, VisionDescription: Discover why labeling your company as an ‘AI Company’ doesn’t resonate with customers; learn what truly matters to them, from value and consistency to safety and vision, in this insightful blog post. Explore how genuine value creation and reliable service, not flashy labels, drive customer loyalty and business success.

Amazing that in less than 24 hours I went from the Smoky mountains to the Rocky mountains and a good 6 hours on the road and a flight to get there.

A Journey Through Time and Technology

My first time to Denver was in 2010 - Perficient flew me out to interview (and offered me a job, and then disappeared - likely due to Oracle’s change of heart around Contact Center Anywhere). I’m literally staring at the hotel that I stayed at at the time. 3 of the past 4 years I found myself in Denver the last school week of the year give or take Memorial day weekend. I won’t get into those last two :).

Attending Zendesk Relate

This year, I’m privileged to attend Zendesk Relate, as a partner, benefitting from the hard work my colleagues at Call Center Power put into demonstrating competency and capability in delivering Zendesk Contact Center.

Zendesk’s Evolution

(If I recall correctly, this is about a year into their acquisition of Local Measure as well). That’s about the time Zendesk popped back up into my radar, having last used it (as a customer) in 2015ish and periodically running into customer opportunities where it was in play. I recall there were a few rough years, nothing to be ashamed of, nor to laugh at. Finding myself leaving my own rough year, I looked back at their story numerous times and felt some relief - challenges happen, and you overcome them. Now, when Zendesk did pop back up on my radar I was amazed - what was a SME ticketing system (in my mind) 10 years ago had grown up. I’m genuinely excited about what I’m about to learn this week.

Learning and Growing

So now, my hope is this week to learn as much as possible - what’s changed in the product (a lot!), what do customers like about it? And, as always, how does that intersect with AWS :)

Behind the Scenes

We have been building some neat things behind the scenes around Zendesk as well, and look forward to sharing them soon. It’s exciting to see the innovations and improvements Zendesk has made, and how these advancements can be leveraged to benefit our clients.

Reflections and Future Outlook

Reflecting on my journey, I’ve seen how Zendesk has evolved not just as a product, but as a platform that continues to adapt to the ever-changing landscape of customer service. The transition from being a simple ticketing system to a comprehensive customer engagement platform is remarkable.

Key Takeaways

• Product Evolution: Zendesk has come a long way, integrating more robust features and capabilities.
• Customer Feedback: Understanding what customers value is crucial for continued improvement.
• Integration with Contact Center Technology: The intersection of Zendesk with broader technologies opens up new possibilities for enhancing customer experiences.

What’s Next?

As I delve deeper into Zendesk Relate, I’m eager to explore the new features, network with other professionals, and gather insights that can be applied to our ongoing projects.

Conclusion

My journey from the Smoky to the Rocky Mountains is more than just a physical trip; it’s a testament to growth, learning, and the exciting advancements in the Contact Center technology space. Attending Zendesk Relate is part of my reignighted passion for innovation in technology to support the front lines of service and support - whether it’s for an internal customer or an external customer.

Stay tuned for more updates as I continue to explore and learn at Zendesk Relate!

I normally have 3+ concurrent activities going on between Claude, Claude Code in Visual Studio Code (VSCode), Kiro and Quick In between waiting for them to finish, or moving to the next step, or asking me questions because I am vague in my requests, I do other things - typical multitasking. Good use of time, right? Then I forgot they are waiting.

Interrupts and Notifications

So what if we think about computers and interrupts? What if these tools become the interrupt to my background activities? Great, we can create a local MCP server (I know, a bad idea for most, but bear with me), use that with these tools, and pop a notification to my screen so I am 1) reminded that it’s here 2) am aware it needs me 3) can give it one of a few obvious responses).

(Tools are tools in the traditional sense, not agent tools, and I am calling it ‘it’, not ‘Barbie’).

Enhancing Efficiency with MIDI Controllers

Neat, now that that works, why not pre-can some responses? I swear I have seen a 3-key USB-C attached device that does this. Well, I have a MIDI controller, which is even better because I lack musical talent.

By configuring my MIDI controller, I can streamline my workflow even further. When I get a popup (or the MIDI pad lights up for the specific tool), I can hit a button, switch focus to that tool, and likely tell it ‘okay go ahead’.

Balancing Innovation and Stability

This is about as willing as I am to go in the world of OpenClaw, because the last thing I need is to end up with a wiped laptop. Of course, Quick has been interesting, but it is starting to show its AWS-ness (can’t seem to add more than one Slack Workspace, though it claims it’s possible, but also doesn’t know where to go to raise a support case, besides the usual suspects, which are not appropriate for a consumer app).

The Project

I called it MPD-Vibe because it’s an MPD218 controller and I’m vibe coding with it. Pretty creative, right? Unfortunately when I got this pandemic-era device I didn’t envision using it for this purpose, so this model only has Red LEDs (other models have the full RGB spectrum).

I started in Claude as an experiment, got some help with Quick to explain to Claude how to setup an MCP server automatically, and tied it off in Kiro for an actual OSX installer and app. Claude also pretended not to know how to light an LED on the controller so google found me a nice GitHub Gist with sample python code (thanks! https://gist.github.com/peterc/7f618761f47b1669068ed4c93c9d0eb2).

Aside from that, some testing yielded various MCP behavioral differences between the tools, state management, blocking and timeout issues, but I think I have them all nailed.

Conclusion

By integrating a MIDI controller with the various flavors of Agentic apps and setting up a local MCP server, you can streamline your multitasking workflow, ensuring you never miss a notification and can efficiently manage multiple tasks across platforms. While diving into more complex systems like OpenClaw might seem tempting, balancing innovation with stability is key. With the right tools and setup, you can enhance productivity without unnecessary risks.

But why not take a page out of the ‘vibe coded a CRM’ playbook and build something using IVS? So I let Kiro build it for me.

Now, I did expect it to work perfectly the first time (spec-driven development solves the shortcomings of AI, right?). Ultimately, it probably spanned 3 days and it’s not perfect, but close enough for me to be comfortable with using it in a month. Despite a very detailed spec, I had to go back through and remind Kiro of some things, do a lot of deployments, and a lot of manual testing (but I have 280 automated tests LOL).

It’s been through a W-A-R (NO, IT’S NOT A WAFR), can be branded for your own community (like a HAM radio club), runs on AWS, deploys via CDK, is serverless, and maybe costs a few dollars an event. Actually, the domain cost more than I envisioned this to cost for the foreseeable future. Donations accepted.

In the end, it’s pretty neat, will be on GitHub soon, licensed in a friendly manner (as soon as I figure out which one), and has a ton of features (nothing earth-shattering). Can you think of anything I missed?

Live StreamingIVS Real-Time Stages - Sub-300ms latency WebRTC streaming for presenters and attendees

• Screen sharing: Share entire screen, application window, or browser tab
• Webcam: HD video (up to 720p) from selected camera device
• Microphone: Audio input with device selection and level monitoring
• Device audio: Share system audio for demos and media playback
• Multi-presenter: Up to 12 simultaneous publishers per stage
• Adaptive bitrate: IVS handles quality adaptation based on network conditions

Green Room

• Staging mode: Presenter previews audio/video before going live
• Device picker: Select camera, microphone, and audio output from available devices
• Preview panel: See exactly what attendees will see
• Go Live button: Single click to transition from staging to broadcasting
• Composition start: Server-side recording begins automatically on Go Live
• Attendee notification: All registered attendees notified when event goes live

Chat

• IVS Chat integration: Native IVS Chat rooms with low-latency message delivery
• Group messages: Visible to all participants in the event
• Direct messages: Private messages sent only to the presenter
• Tab filtering: Switch between ‘All’, ‘Group’, and ‘Direct’ message views
• System notifications: Automated messages for role changes, event state updates
• Chat toggle: Presenter can enable/disable group chat during session
• Persistent room: Chat room created with event, persists across session restarts

Q&A

• Submit questions: Attendees submit text questions to the presenter queue
• Answer with text: Presenter types a response; answer broadcast to all attendees
• Pin Q&A: Pin important questions to the top of the attendee view
• Unpin Q&A: Remove pin to return question to normal position
• Question history: All questions preserved with status (queued, answered, dismissed)
• FIFO ordering: Questions displayed in submission order
• Dismiss: Presenter can dismiss irrelevant questions from the queue

Hand Raising

• Raise hand: Attendee signals desire to speak or ask a question
• Lower hand: Attendee can lower their own hand
• Presenter acknowledge: Visual indicator that presenter has seen the raised hand
• Presenter dismiss: Lower a specific attendee’s hand without granting speak
• Lower all hands: Clear all raised hands at once
• Grant speak permission: Promote attendee to publisher (mic goes live)
• Revoke speak permission: Return attendee to subscribe-only mode
• Ordered list: Hands displayed in chronological order (first raised = first in list)

Presenter Dashboard

• Attendee list: Real-time list of all connected participants with roles
• Question queue: Incoming questions in submission order with action buttons
• Hands panel: Raised hands with acknowledge, grant speak, and dismiss actions
• Role indicators: Visual badges for organizer, co-presenter, attendee roles
• Connection count: Live count of connected attendees
• Session timer: Elapsed time and remaining duration display

Moderation

• Mute audio: Remotely mute a participant’s microphone
• Restrict chat: Prevent a specific user from sending group messages
• Kick: Remove a user from the live session (can rejoin)
• Ban: Permanently remove a user (cannot rejoin the session)
• Ban system: Banned users stored in DynamoDB; checked on connection and token generation
• Admin API: Disable/enable Cognito user accounts for platform-level bans

Event Duration

• Scheduled end time: Events have a defined duration set at creation
• Auto-stop: EventBridge Scheduler triggers automatic session stop when duration expires
• Countdown timer: Client-side countdown displayed to presenter and attendees
• Extend duration: Presenter can extend the event by 15/30/60 minutes
• 5-minute warning: Broadcast notification when 5 minutes remain
• Graceful shutdown: Auto-stop triggers composition end and attendee notification

Recordings

• Server-side composition: IVS combines all publisher streams into a single HD recording
• HLS format: HTTP Live Streaming with .m3u8 manifest and .ts segments
• CloudFront delivery: Recordings served via CDN with CORS headers
• HLS.js playback: Browser-based player for recording playback
• S3 lifecycle: Recordings transition to IA (30 days) then Glacier (90 days)
• Recording metadata: Duration, participant count, and timestamps stored in DynamoDB
• Publication pipeline: Automatic GitHub Pages publication via EventBridge + Lambda

Email Notifications

• Six email types covering the full event lifecycle:
  • Event Created: Event creation, Organizer
  • Signup Confirmation: Attendee registers, Attendee
  • Event Reminder: 1 hour before start (EventBridge Scheduler), All sign-ups
  • Event Started: Go Live, All sign-ups
  • Event Cancelled: Event deleted, All sign-ups
  • Event Recap: Recording published, All sign-ups

Amazon SES: Transactional email with DKIM domain verificationEventBridge Scheduler: Time-based triggers for reminders and auto-stopDead letter queue: Failed emails captured in SQS for retry/investigationFire-and-forget: Email sending is non-blocking (async Lambda invocation)HTML templates: Branded email templates with event details and action links

Custom Domain

• Route53 hosted zone: DNS management for awsvirtualmeetups.com
• ACM certificate: Wildcard TLS certificate (apex + *.awsvirtualmeetups.com)
• CloudFront custom domain: Frontend served at awsvirtualmeetups.com and www.
• API Gateway custom domain: HTTP API at api.awsvirtualmeetups.com
• WebSocket custom domain: WebSocket API at ws.awsvirtualmeetups.com
• DNS validation: Automatic CNAME record creation for certificate validation
• A record aliases: Route53 alias records pointing to CloudFront and API Gateway

Authentication

• Cognito User Pool: Email-based sign-up with verification
• SRP authentication: Secure Remote Password protocol (no client secret)
• Email verification: Required before account activation
• Custom role attribute: custom:role (organizer or member)
• Role-based access: Organizers can create/manage events; members can attend
• API Gateway authorizer: Cognito User Pool authorizer on protected HTTP routes
• WebSocket auth: Token passed via query string on $connect
• Advanced security: Audit mode for compromised credential detection
• Account lockout: 5 failed attempts triggers 15-minute temporary lock
• Identity Pool: Federated identity for AWS service access

Observability

• CloudWatch dashboard: Single pane of glass with API latency, errors, Lambda duration, DynamoDB capacity, WebSocket connections, and engagement metrics
• CloudWatch alarms: API error rate, Lambda errors, DynamoDB throttling, WebSocket failures, high Lambda duration
• SNS notifications: Alarm actions send to email subscribers
• Structured logging: JSON-formatted logs with correlation IDs, action names, and context
• Log retention: 30-day retention on all Lambda log groups
• Saved queries: CloudWatch Logs Insights queries for errors, slow invocations, disconnections, failed auth
• IVS metrics: EventBridge rule captures stage participant events for custom metrics
• Engagement metrics: Custom CloudWatch metrics for chat messages, questions submitted, attendee count

Security

• WAF (CloudFront): CLOUDFRONT-scoped WebACL protecting the frontend distribution
• WAF (API): REGIONAL-scoped WebACL for API Gateway protection
• Rate limiting: 100 req/min unauthenticated, 500 req/min authenticated (per IP)
• AWS Managed Rules: Common Rule Set, SQL Injection, Known Bad Inputs
• Size restriction: 4KB max body for WebSocket/chat payloads
• CORS: Strict origin allowlist (awsvirtualmeetups.com only)
• Input validation: Server-side validation on all Lambda handlers
• Ban system: User-level bans stored in DynamoDB, enforced on connect and token generation
• S3 block public access: All buckets use BlockPublicAccess.BLOCK_ALL
• Origin Access Identity: CloudFront accesses S3 via OAI (no direct S3 access)
• SES DKIM: Domain-level email authentication to prevent spoofing
• Cognito advanced security: Compromised credential blocking, adaptive authentication
• HTTP 429 responses: Custom WAF response body for rate-limited requests

I had mastered the webinar multitasking thing in the 2020s but in the past few years just couldn’t manage it, but made it work yesterday. Mainly because I was interested in Connect and was hoping to get some nuggets of what the NLX acquisition meant for Connect. New SKUs, as others put it, seemed to be the primary topic of discussion, which is good and promising, but with the current set of materials, doesn’t really paint a complete and understandable picture.

As a side tangent, I am surprised that both the document history (https://docs.aws.amazon.com/connect/latest/adminguide/doc-history.html) and release notes pages (https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-release-notes.html) are light/incomplete/delayed in providing information, and I have to go to the Newsletter (https://newsletter.connect.aws.dev) to figure out what’s going on, which tends to put me up to a month behind. Despite all these advancements in AI, something that’s become very evident to me, especially in the last year, is despite talent, despite technology, you still need process. I’m going to assume that AWS’ mass layoffs and poor hiring practices (despite academic justification for them) is playing a role until I am told otherwise. By the way, there are about a dozen pages like this I check daily, some not updated in well over 2 years. I wonder why I keep checking? On occasion there is a serious update, which keeps me coming back.

Having invested just short of an hour and a half yesterday, and finding myself with more questions than answers, and general confusion, I sought validation from the Internet, granted, not very in depth (LOL maybe I should have used AI), and since Twitter’s destruction, do not have a very solid place to go anyway (right now Instagram thinks I’m obsessed with 3D printing).

Deeper Dive into the Event and Its Implications

The AWS What’s Next event was anticipated with much excitement, especially considering the recent developments in the tech industry and AWS’s continuous push for innovation. The event’s abrupt conclusion left myself scratching my head. The studio design and the outfits worn by the AWS team were notably modern and visually engaging, setting a fresh tone for the event. (Nova re-wrote that, BTW, I was not very nice in what I had to say).

Connect and the NLX Acquisition

My primary interest in the event was Amazon Connect and the implications of the NLX acquisition. The focus on new SKUs is promising, indicating AWS’s commitment to enhancing its offerings. However, the materials provided post-event were lacking in depth, leading to more questions than answers. This highlights a broader issue: the need for comprehensive and timely documentation. The document history and release notes pages were sparse, and the newsletter, while helpful, often left me playing catch-up. This is a critical area for improvement for AWS.

The Importance of Process

One of the key takeaways from the event, and my experience with AWS in general, is the importance of process. Despite the talent and technology at AWS, the apparent lack of a robust process has led to delays and gaps in communication. The mass layoffs and subsequent hiring practices, while justified from an academic perspective, seem to have had a tangible impact on the quality and timeliness of updates and documentation.

Exploring New Tools and Features

Amid the confusion, there was a silver lining: the introduction of a new fat client for Quick. This app, previously known as Quicksight, is set to absorb Q for business purposes (in my opinion). The return of the fat client, or app, is something I’m genuinely excited about. These apps provide a more focused and less cluttered experience compared to browser tabs. I’ve already downloaded and installed the app, connected it to various services, and started exploring its features.

Security and Trust in Data Usage

One of the reasons I feel more comfortable with AWS’s approach is their practices around security and data usage. While I am hesitant to give Open AI access to my data, I trust AWS more in this regard. The app offers a promising way to organize my information, communications, mail, calendar, and files in a way that feels comfortable and secure.

Looking Ahead

With an update already available and the app not yet reaching version 1.0, I anticipate a rapid evolution similar to Kiro. I’m hopeful that this new tool will help streamline my workflow and look forward to potentially paying for a subscription once the trial ends. The journey with AWS continues, and I remain optimistic about the future developments, despite the current challenges.

The Early Days: A Skeptical Beginning

Before AWS, I had not put much value in certifications, except when I was about 14 and I heard that Cisco Certified Engineers made ‘a lot’ of money. My initial skepticism towards certifications was rooted in the belief that practical experience and hands-on skills were more valuable than paper qualifications.

Promero and Oracle: A Detour into Middleware

At Promero, I achieved a certification from Oracle for a product that has been long deprecated (how long until there is a TikTok certification?). It was a time of exploration, and I began to delve into middleware technologies. However, my curiosity was piqued by the emerging world of cloud computing, and I found myself getting distracted by this new and exciting domain.

Pega: The First Cloud Encounter

Then, at Pega, I tried for my Certified Solutions Architect (CSA) and failed. It became clear that missing even a day (or a week) of training could lead to gaps in foundational knowledge. However, I passed successfully on my second attempt, albeit purely by luck, and without truly grasping the foundational concepts. This knowledge was more relevant for building on the product rather than running it, and since my role was focused on running the cloud product, these foundational elements were less critical. Nonetheless, the experience was enlightening.

A SaaS Revelation and DCO Process Transformation

Sometime in the past year, I signed up for a trial and was amazed at two key aspects: 1) How SaaS-like the experience was and 2) How prompt-based building completely changed the Document Composition and Output (DCO) process. This revelation underscored the transformative power of cloud technologies and set the stage for deeper exploration.

CloudHesive: The Hook

Then finally, for what I consider the first day of CloudHesive, I took the Solution Architect Exam (at the time there were five exams in total). Naively, I didn’t study, but I did pass. In hindsight, there were definitely questions I got wrong, I believe around EC2 instance roles, because they were so new (LOL). I got hooked at that point.

Pursuing the Full Set: A Rapid Learning Curve

Fast forward, I had to get the other two associate-level certifications within about a year to help us move up the ladder in the partner ecosystem. I might have taken them back to back, but it’s blurry at this point.

re:Invent and the ‘All Five’ Milestone

Then I found myself at re:Invent. The ‘all fivers’ (again, the total number of exams at the time) all fit in a photo. It was a proud moment, and at a later summit, I even saw someone from another partner get a cake for getting their ‘all five’. I wanted cake.

The Professional Journey

Later that year, I went for both the professional certifications - either 1 or 2 days apart. All five of these certifications I took in person (the only option at the time) at the same time of day, at the same day of the week (morning, on a Friday or close to it if I was doing back to back). Why? Superstition. Also, if I passed, it was a nice start to the weekend.

Consistent Study and Preparation

At this point, I had maybe 5-6 years of experience with AWS, but the first few years I did it wrong, and the other years I might not have had exposure to the full set of services covered in the tests. So, I spent nearly every Sunday studying for about 4 hours - read - make my own labs - read some more. I also took the early practice exams, which failed me as much as I failed them. Regardless, I passed the real exams the first time.

Continuous Learning and Contribution

Through all that, I got a chance to contribute and witness their increased quality. As we see below, there have been exams to come, and exams to go. The journey continues, with a commitment to continuous learning and improvement.

Conclusion

Reflecting on this journey, the value of certifications has become clear. They not only validate my skills and knowledge but also open up new opportunities and pathways in the ever-evolving world of cloud computing.

I ended up building more of a landing page than a blog (perhaps what LinkedIn could be? Or a really powerful LinkTree-like site). My initial goal was to create a simple showcase of my work and achievements, but as I delved deeper into the project, it evolved into something much more comprehensive and robust.

Delving into the Scraping Process

Gathering Data from Various Sources

To create a landing page that truly represents me, I had to gather a significant amount of information from various sources. This process involved dealing with both public and non-public APIs, which presented its own set of challenges. While Kiro’s warnings about the risks of using non-public APIs were very much valid, the data I scraped was essential in creating a comprehensive and personalized landing page.

Scraping data from APIs was relatively straightforward and provided the foundation for my landing page, ensuring that it was both informative and reflective of my professional journey.

Building a Custom CMS

The Need for a Content Management System

As I started aggregating data, I quickly realized that I needed a way to manage and edit these pages effectively. While WordPress is a popular and powerful option, I chose to create a custom content management system (CMS) to avoid the usual security and operational concerns associated with WordPress. This decision allowed me to have full control over the development process and to tailor the CMS to my specific needs.

Creating a Local Client

The custom CMS I built is designed to run locally on my machine. This local client ensures that all the code is executed in a controlled environment, providing a seamless development experience. Once the code is ready, it is versioned and pushed to GitHub. However, the CMS is flexible enough to work with any static hosting site solution, giving me the freedom to choose the platform that best suits my needs.

Enhancing Visual Appeal with Jekyll

To handle the visual aspects of my landing page, I used Jekyll, a popular static site generator, combined with a well-crafted template. Jekyll’s simplicity and flexibility made it an ideal choice for this project, allowing me to create a visually appealing and professional-looking website without the need for complex server-side scripting.

Enhancing the Project with Additional Features

To further enhance my landing page, I created several additional features that improve both the functionality and user experience.

Media Library Manager

Organizing and Managing Media Files

One of the key features I added was a media library manager. This tool is essential for organizing and managing all the media files I use on my site, such as images, videos, and presentations. It also deploys and manages the content delivery network (CDN), ensuring that my media content is efficiently distributed and accessible to users worldwide.

Keeping Content Up-to-Date

In addition to managing media files, the media library manager extracts and re-tags common tags from YouTube and SlideShare content I have previously authored. This ensures that my landing page always showcases the most relevant and up-to-date information. With nearly 200 references, having a well-organized media library is crucial to avoid overwhelming visitors with too much information.

URL Shortener

Simplifying Long URLs

Another crucial addition to my landing page is a URL shortener. This feature simplifies long URLs, making them more user-friendly and easier to share. It also helps with tracking and analytics, providing insights into how users interact with my content. By shortening URLs, I can monitor which links are most popular and adjust my content strategy accordingly.

YouTube Synchronization

Keeping Content Fresh and Engaging

To keep my content fresh and engaging, I implemented YouTube synchronization. This feature automatically updates my landing page with the latest videos from my YouTube channel, ensuring that visitors always have access to the most recent content.

Editorial Assistance with Bedrock

Maintaining High-Quality Content

To maintain high-quality content, I integrated Bedrock, as an editorial assistance tool. Using basic prompts, Bedrock helps with spelling and grammar checks, as well as elaboration and generation of titles, descriptions, and tags. This feature ensures that my content is polished and professional, while still remaining authentic to my voice and style. By leveraging AI-driven editorial assistance, I can focus on creating high-quality content without worrying about minor errors or inconsistencies.

Balancing Efficiency and Effectiveness

While this project isn’t ‘agentic’ in the sense of being fully autonomous, it strikes a balance between efficiency and effectiveness. By building a custom CMS and adding these additional features, I created a landing page that is not only functional but also serves as my portfolio. This balance ensures that I meet my needs while keeping costs and resources in check.

Conclusion

Creating a personal landing page turned out to be more than a 24-hour project, but (and the same can be said about nearly any AI project), it came down to data quality. I found this to be a great exercise in using Kiro to build something that sees the light of day (versus the other dozen or two projects I’ve not yet deployed). The journey of creating this landing page has been a valuable learning experience, providing insights into the intricacies of scraping APIs, building a custom CMS with Jekyll, and the balance between efficiency and effectiveness in personal projects.

I used my AI friends to help get to a conclusion - host it on GitHub. No different than Code and I alone determine how my intellectual property is used and by who. The problem is, the workflow around publishing to GitHub, and writing in Markdown puts me back into a spot I was in previously.

The other issue is reach - how can I use friendlier platforms (ideally ones with APIs and are geared towards the community of developers) to syndicate my writing elsewhere?

I’ve been using Kira A LOT, nothing (recently, at least) has made it to the Internet, so this is the first. I used Kiro to help me create a browser based (albeit local) “application” that handles the editorial lifecycle of content drafted, reviewed and published by a singular person (so no sharing, RBAC, etc.) with a heavy focus on the publishing workflow and syndication.

After about a dozen tests (I see Twitter, I mean X is still desparate for money and posting through an API is nowhere near free), I am able to post to GitHub, Dev.to, Hashnode and a link from “Linked” In to the GitHub based Blog. Twitter sure would be nice, as would the AWS developer community portal (hint hint). Medium and Substack seem to be less than intersted in API-based posting, and based on some of Medium’s practices in the past, I am less interested in posting there (Substack is still promising, though).

Perhaps in the future I’ll cross post to Slack, eh?

Anyway, this is the first test post I won’t delete, and I’m proud that it cost me zero hard dollars and about a day or so to incept, iterate and begin using.

Patrick

AWS to the Edge

Trans-Oceanic Cables

What we are looking at is data flowing across AWS regions via a single operational and administrative domain. All of this is owned and controlled by AWS. To ensure speed and quality of service, multiple parallel 100 gigabit links are used crossing the world’s oceans. A single link cut will not impact operations.

Cable types used in inter-region connectivity:

• SL17 Lightweight: Buried in the ocean, used where there are minimal risks to a link-cut
• SL17 SPA: Protects against light abrasion — also known as ‘Fishbite’ protection
• SL17 Light Wire Armor: Protects against harsher abrasion — such as fishing and anchors
• SL17 Double Armor-HS: Higher grade of protection guarding against greater hazards

These undersea cables run through repeaters, which supply electrical power 3 miles under the sea and are supposed to last 20 years. In the event of a link cut due to a fishing trawler accident, the voltage is doubled on the non-cut cable while the link is serviced. Seawater is used as a ‘third cable’, keeping the link operational while the damaged link is repaired. This equates to no loss of service for the AWS region.

Custom MACSEC Switch

AWS uses custom network switches to encrypt traffic leaving Amazon buildings. All customer data is secure and isolated from other AWS customers. MACSec is an IEEE Standard that ensures confidentiality, integrity and authenticity of your data. This can be used in Direct Connect connections from your corporate data center to AWS. For more information, see MAC Security — AWS Direct Connect.

AWS Direct Connect

AWS allows customers, via Direct Connect, to create private, physical connections to AWS Points of Presence globally, which provide a direct path between AWS and customer facilities where consistent, dedicated connectivity may be preferred over Internet based connectivity.

AWS Private 5G

Moving from the sea to the Air, AWS Private 5G allows site-wide deployment of wireless networks based on the 5G standard, in areas not otherwise covered by a mobile network operator and/or in environments in which WiFi is not feasible (such as large equipment and container yards). The service includes the radios, software, SIM cards and supporting infrastructure. All you need to provide is power (even PoE works!), Internet, spectrum and a certified professional installer.

Amazon Project Kuiper

From the Air to the Sky, Amazon Project Kuiper will create a constellation of low earth orbit (LEO) satellites with the goal of providing low latency, high throughput Internet service to underserved communities of the world, connected via AWS operated Ground Stations.

AWS Ground Station

Available independently from Project Kuiper, AWS Ground Stations can be used to retrieve data from satellites or send command and control signals to them, through pre-arranged timeslots on an on-demand or committed consumption based price. Ground stations are deployed globally and support LEO, NGSO, and MEO satellites operating at S and X Bands.

AWS Local Zones

AWS Local Zones offer a subset of the AWS services and can be found in regional metropolitan areas, intended for low latency applications or applications with specific data residency requirements.

AWS Wavelength

Like AWS Local Zones, AWS Wavelength Zones offer a subset of the AWS services co-located with popular 5G carriers, providing low latency, high throughput access to services from mobile devices connected to 5G networks.

AWS Outposts

Probably one of the most direct forms of physical cloud are AWS Outposts. At first glance, it’s a physical server delivered to you, running AWS. This is the answer to several questions: What if the nearest public cloud servers are not near enough? When extremely high performance is needed (think single-digit millisecond latency) — Outposts can be used here. This has applications in Medical, Gaming, Manufacturing and Logistics, particularly Maritime. They are also very useful when dealing with strict data residency requirements.

Once you rack and stack AWS Outposts, the services are fully managed by AWS, giving you the same benefits of reducing operational overhead, including physical support. All the same tools and APIs you use with AWS Cloud you can use with AWS Outposts.

AWS to the Consumer

The AWS Snow Family

The AWS Snow family, consisting of the Snowcone, Snowball, and Snowmobile — devices used to facilitate small and large scale data transfer, along with providing compute on a number of these devices. Here at CloudHesive we used the SnowCone along with a running instance of the AWS DataSync agent to persistently synchronize data from logistics warehouses to AWS, providing just-in-time, catalog quality images of new inventory. Snowcone is so sturdy that AWS sent one into orbit on the International Space Station.

For larger workloads, AWS provides Snowball and Snowball Edge. The Edge device provides its own local compute and integrates with AWS Lambda and Amazon S3.

AWS Snowmobile provides the largest data transfer capability, in the exabyte range — which comes in a shipping container pulled by a very large truck.

AWS DeepRacer

AWS DeepRacer is a very accessible entry point to get started with machine learning. AWS offers AI/ML scholarships and a DeepRacer league. Each year the professional league championships are held at re:Invent. You can get started here.

AWS DeepComposer

Like DeepRacer, AWS DeepComposer is another gateway for developers to start with machine learning. It is a creative and fun way to get started with a real musical keyboard. Generative melodies are constructed via your input blended with artificial intelligence.

AWS DeepLens

DeepLens is a wireless and programmable camera that can be used for image detection and deep learning. It integrates with SageMaker to create your own machine learning models, or you can use pretrained ones. It also runs Amazon IoT Greengrass, one of a few purpose built operating systems intended for IoT devices.

AWS IoT Button & EduKit

The AWS IoT Button is a WiFi connected, embedded IoT device for developing basic AWS-based IoT applications. The AWS IoT EduKit builds on those concepts with a complete hardware platform including I/O, LEDs, Touchscreen, Haptic feedback, IMU, Temperature sensor, microphone/speaker on an ESP32 compatible CPU.

Amazon Alexa

Amazon Alexa, introduced in 2014, combines the power of Cloud, Natural Language Understanding (NLU), and purpose-built hardware. Developers can build skills, host their backend on AWS (serverless!) and publish to a marketplace. A related engine, Lex, is available as a standalone AWS service that can power Contact Center platforms including Amazon Connect.

Amazon Monitron

Amazon Monitron is used for industrial equipment monitoring via AWS. CloudHesive worked with Tidewater Block — a family-owned manufacturer and distributer of building and masonry products — to deploy Monitron. It uses sensors to capture vibration and temperature data from equipment, a gateway device to securely transfer data to AWS, and machine learning to analyze the data for abnormal machine patterns and predict failures before they happen.

AWS Panorama

AWS Panorama does for Computer Vision what Alexa does for Natural Language Understanding, and comes in two flavors — a dedicated appliance capable of taking video stream data from IP cameras or an embedded device produced by third party partners. It leverages machine learning on AWS to perform high speed local predictions in milliseconds.

AWS Elemental Appliances

In 2015 AWS acquired Elemental Technologies, which produced software for video encoding, decoding, transcoding, and pixel processing. This software, traditionally bundled with hardware, was made available via cloud service models but appliances are still available for studio or other settings where local processing is preferred.

Conclusion

While AWS provides truly hyperscaled public cloud services, its building blocks, connectivity and over a dozen services have a physical component involved — many that truly allow you to reach out and touch the cloud.

— Jorge Rodriguez, Senior Lead Cloud Engineer, CloudHesive and Patrick Hannah, CTO, CloudHesive