It's as if the lightbulbs in my brain were all replaced with dimmer switches when I joined Trility Consulting a year ago. I had an opportunity to learn yet another industry in my marketing career and before me were some really smart, pragmatic experts willing to teach me.
As a journalism major from a long, long time ago, I thought my curiosity and ability to ask any question without feeling stupid would be invaluable. Don’t get me wrong, they were. However, learning how software developers and engineers build technology solutions in the cloud has so many facets there were questions I didn’t even know to ask. The golden nuggets always seem to come from follow-up or clarifying questions.
I’ve had several light bulb moments in the last year. So many that I now describe these moments as my light bulb is now just less dim. My colleague describes it as...
Your learning light gets brighter as your understanding increases over time.
So I’m sharing the lesson and explaining in terms that hopefully even non-technical business leaders and decision-makers can understand.
Why? Moving your business to the cloud was critical in sustaining your business before COVID-19. Now, it’s necessary. And it’s necessary that you transform your business for the better vs. just move it to the cloud.
Finding value in a cloud solution requires constantly nudging that dimmer switch up to steadily optimize performance and reduce costs – and it requires 100% code.
To demonstrate this, I’m sharing my first so-called light bulb moment and then how nine months later, I didn’t truly grasp the lesson in that moment. I must admit, it shames me a little bit as a journalism major. However, I’ve been told this lesson isn’t easily grasped – especially by non-technical people, even leaders and decision-makers who are in a position to really transform the way companies operate.
Last fall, I sat in a lunch ’n’ learn and I asked about how Identity Access and Management (IAM)* permissions work in Amazon Web Services (AWS). In a previous job, I had a part in helping adding/adjusting/deleting users and permissions, so I had a basic understanding of how to maintain users in an on-premise environment.**
*IAM regulates who has access to what and to what extent, i.e., role-based permissions.
**On-premise means your servers, applications, databases, etc., all exist on-site and you most likely have a locked server room that is very chilly and a great place to cool off if you’ve biked to work.
The person leading this session showed how Trility typically approaches centralized IAM permissions to ensure the highest security practices. It’s done in code vs. what I remember being a series of menus and checkboxes to update/add/remove roles or users to our on-premise server. Which also meant it was on-demand and manual. Giving access to a new hire meant I could be a blocker for them to login.
I asked, “So it’s like the Matrix? Everything is code?”
Answer, “Yes.”
My clarifying question, “Is everything in code?”
Again, “Yes.”
Sweet. My light bulb popped on. Or so I thought. It was really just less-dim.
I walked away from this conversation assuming everything built in the cloud had to be 100% code and this is how everyone does it.
Fast forward to this spring: I learned, unfortunately, not everyone builds in the cloud using 100% code. To take full advantage of the cloud, you need to consider doing it all in code – or at least take the steps towards it.
I offer up my cheat sheet of what those full advantages are and what that translates to those who don’t code.
This light bulb moment happened at another lunch ’n’ learn where an example AWS instance was pulled up for an upcoming DevOps Meetup our company was hosting in Omaha. It provided a visual context and I asked a question that off-handedly led to learning that some people may click through settings vs. writing permissions in 100% code.
For those interested, here’s the video of the DevOps Meetup where you can learn how to manage multiple AWS resources spread across AWS multiple regions in a simple, cost-effective way using Terraform.
“So you don’t have to code in the cloud?” I asked.
“No,” was the short answer.
I got a longer answer explaining why, but will offer a less-long answer in my terms:
Yes, there are just as many menus and boxes that can be checked in AWS, Google, Azure, or any other cloud services provider.
Yes, it will allow you to move to the cloud in days, weeks, or even one month and you could even possibly do a complete lift ’n’ shift, which is pretty much always a bad idea but there could be a valid, contextual reason. And if you do this, you can’t just walk away and consider it done. You need to refactor everything and do it very, very quickly.
You can choose this route, but...
And it’s a big but.
It won’t allow you to reap the benefits of cloud computing. Going this route, you could end up paying more or not achieving the return on investment that everyone sells: Move to the cloud. It costs less.
Innovating with the full power of the cloud at your disposal AND saving time, money, team capacity requires doing the work in code and building reusable patterns.
I asked this once and here’s my answer:
Think of code as a living template that’s housed in a repository which serves as the single source of truth for every digital aspect of your business. It is updated in one place and is pushed out (deployed) to all the places that use this code. For example, if you have IAM permissions that are both centralized and automated, this code can be reused for any new application that is needed. If you were developing a new application, the software developer can use automated tests (or at least manual, daily tests) against that code to confirm permissions and logins work for a new application. This applies to “any code templates” for automated critical integrations (such as security measures). This translates to bugs and issues being found daily vs. waiting to reactively try to solve them a week or months later when the application needs launched.
As a marketer, I just uncovered a major value proposition for my company and I didn’t learn it until 10 months into the job. By assuming everything built in the cloud had to be code, I did not realize this was a differentiator for Trility. It can also be a differentiator for your business.
(Yes, my marketing head hangs in shame, but my journalistic brain says: “Hey, people need to know this, so share.”)
While Trility isn’t the only firm with this mindset, there are several companies and individuals who haven’t had the capacity to fully leverage this approach. In the race to move to the cloud, companies have many challenges, one of which is capacity.
Technology teams are busy maintaining IT systems. Moving to the cloud requires learning a new way of working. You may hire a team or contract people to come in and do the work. When choosing these options, I encourage you to ensure your contracts include training or documentation that equips your people for maintaining and iterating with the necessary “future-state skills.” Otherwise, you just have a new system and a new vendor who has guaranteed themselves billable hours for months or years to come.
To change the way you do business in the short- and long-term, you need to enable your own teams for the long haul. My advice to those midway through a migration, operating in a hybrid situation, or still contemplating how to do it:
Whatever you do, ensure in the contract that you are setting up your people for success when the contract ends. At Trility, we’ve found great success in providing services in this way.
What I've learned so far is, the cloud isn't just another datacenter. It is a new way of doing work. I realize I'm only scratching the surface. However, as I learn more and more about value propositions, 100% software-defined cloud is making more and more sense to me daily.
If you found this insightful, read: My Cheat Sheet for Understanding the Benefits of Cloud Computing. It builds on this article to help you understand what the heck this stuff all means.
I plan to keep sharing my less dim light bulb moments in the simplest of terms.
If this article sparked thoughts or questions, I’d love to hear them so I can continue to bring clarity to a complex and now a very necessary way to do work. Feel free to connect with me on LinkedIn or email me.
