Far from being all about free USB-C cables and t-shirts, vendor expos and summits are the spark of inspiration we all need.
It’s that time again. You’re a senior manager or leader overseeing one or more engineering functions and the email has arrived in your inbox.
“Early registration now open for AWS Summit/RE:Invent/RE:Mars/Event/Expo, book now!”
You know what comes next. There’s the ask.
The ask to attend.
The ask to go.
Hotels? Plane tickets maybe? Meal vouchers? Uber costs? Has this guy seen the latest company quarterly results? We’re not doing so great. It’s not a red alert or anything, but numbers are down, departments are reigning in spending, and we’ve got a lot of work we need to deliver.
This just isn’t the time.
It wasn’t the time last year either.
Or the year before that.
Maybe next year, when things pick up.
Is this the kind of response you get from your workplace when you ask if they will send you to the latest AWS Summit, RE:Invent or RE:Mars? Or to that awesome lunch & learn that is being put on to teach people about how to migrate from on-premises servers to containerisation?
Whether the reasons are financial, time-constraints or simply no reason at all, it’s safe to say that you’re not alone. Every year organisations like AWS invest time, effort and money into putting on some fairly extraordinary cloud conventions, summits and expos, not to mention the dozens of smaller and more intimate industry vertical or technology specific sessions that dot the professional calender from one end to the other, and every year people aren’t supported to attend or — worse — they don’t even consider attending.
If you’re workplace isn’t supporting you or your teammates to attend these types of events then feel free to use this article as a digital cudgel to beat the offenders over the head (metaphorically, of course) because what I hope to do here is give at least some clarity on why these events are important — no, more than important — critical! — and why it’s important to say yes.
I thought about just providing a list of reasons why these events make sense. A sort of ‘dot point parade’ of the goodness of tech events, but I think anyone using a little common sense can visualise that list for themselves. It’s not hard. Rather I think I’ll give you a personal story instead. A story that involes taking you on a little journey back in time.
A journey to the pre-cloud James.
A journey to the before times.
To the beginning.
(Cue a slow fade to black and a montage of calender pages falling away, revealing the continued slide of dates back into the past. November turns into August, August into March, 2023 gives way to 2022, then 2021, pages continue to fall away faster and faster until eventually the calender settles on 2017…..)
Day One
Before I attended my first AWS Summit, I’d never been to a cloud convention, expo or event before.
I wasn’t even particularly savvy about AWS or the cloud in general. I mean, I knew what it was, and I’d seen a few EC2 instances in my time, but it was always a sort of abstract concept and certainly not something that I really had to deal with in my day-to-day. I had a strong background in .NET engineering, but nearly always started my thinking process from the application up, and very much in a world where the environments were tangible. Servers in stores, machines in a warehouse, that sort of thing.
By the time I started to tap away at the keyboard, servers had been spun up, IIS had been configured and SQL servers were ready to fill with delicious tasty schema. Typically whatever I was buidling or helping others to build was fairly traditional. Awesomw work was done mind you, but cloud just wasn’t a huge part of the vocabulary.
I can’t honestly remember how it came to be that I attended the AWS Summit in Sydney that year. I think maybe someone else from my work was going, and they had a spare pass, so they asked if I wanted to attend.
I didn’t know what I was in for but figured a 2 or 3 day event talking about technology could be a positive experience and besides, a trip is always fun — I’m a sucker for airports and hotels, always have been.
Going into the specific happenings of the first day at the summit isn’t really the part I want you to focus on, so I’m going to skip over most of it, needless to say my head felt like it was spinning by the time the afternoon had rolled around.
A few things had become immediately clear to me.
Firstly, AWS clearly invested a lot of time, effort and energy into these events. Sometimes when we think of a tech summit it can be all too easy to imagine it’s just a massive excuse by vendors and tech companies to sell, sell, sell, covered by the thinnest veneer of innovation or education. It’s this view that can provide fertile ground for the “No’s” we tend to hear from senior management when we ask to attend.
It was clear to me from my day one experience however that this wasn’t the case. Sure, there were booths for companies wanting to sell you stuff — a whole floor of them in fact — like some kind of gladitorial arena where tech companies are the lions and us devs and engineers the doe eyed prey, but that was one very optional component. Outside of that floor, there were a wealth of presentations, learning hubs, coding hackathons and breakout sessions that covered every single type of service or technology you could imagine.
For a brain in learning mode it was nothing short of a bounty.
Inspiration
I told you I didn’t want you to focus on what happened during the day, right? What I want you to think about is what happened to me _later _that evening.
I felt inspired. I felt energised. In that one day I’d been awakened to entire architectures and ways of thinking about delivering value through tech that I’d just never considered. I was tired and my feet were sore, but my mind was alive. I went straight back to the hotel, opened up my laptop and did the only thing that made sense.
I signed up for an AWS account.
From there, I started experimenting. It was my first foray, so heavy on the ClickOps as these things so often are, but I started to play, and build, and build and play. I built a queue with the Simple Queue Service, and marvelled as I could deliver and read messages from it, learning all the while about visibility timeouts and at least once delivery.
I spun up an EC2 instance, and wrote some PowerShell to send a message to the queue containing the details about the instance itself. Lego blocks were starting to fall together around me. I created a Lambda function, and connected it to some other widget — I don’t remember what it was, but I remember the feeling. Exhilerating.
That night I think I burned maybe 6 hours straight just experimenting? that feeling of possibility, of innovation at my fingertips, started then and has never really stopped. I’ve done so much since, deep dived and built with into just about every service and solution in AWS, and done similar with Azure and GCP, but that feeling is still with me as I see out the close of 2023 and the herald of 2024.
I came back to work after the 3 day event, and I talked to everyone about the cloud. The possibilities, the way you could work with different languages, the opportunity so many of the services offered so that you weren’t building from scratch. Over the coming months and years I not only became as proficient as I possibly could in cloud technology in order to create as much value as I could at my work, but I brought other people along for the ride, trying to pass on some of the inspiration I felt onto others, to start their journey towards what I saw as an accelerator and multiplier of already existing talent within our engineering teams.
Now I’m not saying for a moment that I expect every person you send to a cloud summit to come back like I did; a rambling malnourished madman having experienced some kind of religious experience out in the technology desert and whose now came back with spooky software powers.
_(Okay, okay so I wasn’t malnourished — the food was actually pretty good — but the rest is on point…)
_
But what I hope you can see — and your leadership can see — is that one of the core pieces of value that you can come away with from these summits, a piece of value you won’t see mentioned in any agenda or keynote, is the simple power of inspiration.
A little inspiration or a lot, it’s still got to be worth the cost of a flight to Sydney and a couple of nights accomodation right? What can inspiration do? Why, anything. For the individual it can increase their productivity, push them towards new ideas, new ways of approaching problems, and when allowed to propogate like a gentle wave through teammates and departments it can bring about tangible positive change.
It’s not even a question of some shiny new service offering or technology that could create that inspiration either, it can be sparked simply by connecting with people. Whether it be with AWS folk who staff these events and who — I can tell you with certainty— put their blood, sweat and tears into their tech demos, breakout sessions and presentations, or colleagues from other organisations, developers, data engineers, managers, leaders, security analysts, these events are full of them. From every industry vertical and corner of the landscape they come, and the possibility of conversations, shared knowledge, experience — these opportunities could be the perfect spark of inspiration your team needs?
Are you going to be the one that says no to that?
Delivering a serverless hail mary
Of course that initial inspiration wasn’t the only boon I got from that first summit, it was the start of a chain of events that saw me able to deliver a tangible technology solution into production — the first of many — that is still running to this day and still delivering a stack of value.
A few months after that initial AWS summit (all the while me burying my head into learning more about the cloud ecosystem and all it could offer) I was part of a project to move from our (then) daily batch-driven integration of sales transactions between physical retail stores and our ERP to something more real-time.
We wanted to move from delivering crucial sales information from hundreds of retail outlets in a nightly load via a hodge podge of FTP servers and flat files to something more modern, responsive and scalable.
I was only on the periphery of the project at the time, involved more than anything in managing some of the resources being provided to the project to ensure physical stores weren’t negatively impacted by the changes but as the project approached go live, with maybe a month or so to go, a bombshell hit. It turned out the vendor provided product we thought would give us the real time replication of sales we needed couldn’t in fact deliver. What it could do was — at best — deliver the sales data in 4 hourly batches, which was so far from real time and so close to the existing daily batch that we might as well have done nothing.
Project status was looking less than ideal, and there was a lot of time, effort and money tied up in the delivery. My small team were approached in a bit of a ‘hail mary’ situation, the question was basically ‘is there anything you can do?’.
Well it turns out, having been to a summit, become inspired and kept on a path of learning and experimenting, there actually was.
So I took everything I’d learned, sat down, and began to architect a solution that leveraged a combination of C# and AWS to deliver — I hoped — exactly what the project was looking for, real time sales transaction replication for each of the 500+ stores in the network to our cloud-based ERP system.
What I ended up designing and subsequently building was fairly simple looking back. I created a couple of windows services using C#, one which would track changes in the stores database related to sales transactions, and the other which would be responsible for picking up those changes. My next job was how to get those transactions from that service into AWS where our ERP was also sitting. I landed on using something simple and robust — an SQS queue.
From that SQS queue, I set up a .NET Lambda which would trigger off events arriving in the queue. Now I’d read enough to know that SQS was not without its pitfalls, nor was Lambda, so I needed to architect for failure. To deal with any nasty surprises I set up a small DynamoDb table which would be used as a way to hold failures, but also as a way to track the state of the messages as they transitioned from the queue to the Lambda and beyond. Within my Lambda function I wrote some code to transform the sales data, then finally post it to a REST API which would then see the message safely arrive at its final destination — our back end ERP system.
It also turned out that on occasion some of our sales transactions exceeded the 256KB limit of an SQS message, so thinking through the problem, I devised a workaround. As each message was tested for size within the store server, if it was found to be > 256KB, I would instead upload the transaction to an S3 bucket, and then send a bit of a ‘proxy’ message via SQS. This proxy message had some header information and a flag which told the Lambda as it pulled the message off the queue, to use the message as a pointer to an object in S3, and process the payload from there instead.
The whole thing looked a little like this:
It was simple, effective and from the moment the moment the message hits the SQS queue entirely serverless. It was built, tested and deployed within a month or so end-to-end.
We dubbed it ‘Store2Cloud’ or S2C for short, and it has been delivering 4 to 10 transactions per second from stores around the country to the ERP system for going on 6 years now without missing a beat. Of course it’s evolved slightly, and we’ve made improvements here or there around cost or performance or stability, but the core solution today is the same as was dreamt up in the heat of a project deadline all those years ago.
It was a solution that simply would not have been possible without leveraging AWS technology, because we needed a solution that could be stood up quickly while not compromising on security, scalability and stability, and I am certain that without that initial trip to the AWS Summit Sydney and the inspiration that followed it would never have existed, and the project would have lurched towards the finish line as a ball of fiery nonsense.
I wouldn’t dare to say that because you’re willing to send your tech team (or indeed others from your organisation) to the next AWS summit or cloud expo you’re going to bring forth project saving solutions or a mass spread of tech inspiration. That’s not the point I’m trying to get across. Let’s call my experience — my story — an extreme case. But even if you sent someone to an event and they came back with 5% or 10% of these feelings? If they came back and passed on their knowledge to 2 other people instead of 10? If they came back and found ways using AWS services — existing or new — to save you money or deliver new value? Isn’t that worth it? Is it really so easy to simply not consider the value that might get added long term to your technology function from keeping your engineers engaged through attendance to vendor and community events — even if they happen to be interstate or even — gods forbid — international?
What price is too high for fostering and nurting a team of inspired, dedicated and continually improving builders who have at their disposal a vast network of peers, colleagues and industry experts who they’ve met and collaborated with in and outside of these events?
Surely, whatever that number, whatever price _IS _too high, it’s far and away more than the cost of a plane ticket and a hotel?
The next time you get asked, say yes. Who knows, you might just be witnessing the creation of the next Store2Cloud?
Top comments (0)