My first 6 months at AWS

calendar May 8, 2018 · 8 min read  ·
Share on: linkedin copy

As you may have heard, late last year I joined Amazon Web Services. I have recently turned 6 months at AWS (or 180 x Day1) and that is often a good point to pause and reflect. Also, I have got so many people asking me how I am doing here that I thought a public blog post would scale better than many 1:1 interactions.

The TL/DR version of it is: it is exactly as I have envisioned before joining; I didn’t have any major surprise; my due diligence was accurate (i.e. I did my homework properly). Actually, it’s probably slightly even better than what I thought.

I will talk (briefly) about the overall culture as well as the Solutions Architect role (my current role at AWS) in more details here below, if you are interested.

The AWS culture

The culture at Amazon is very interesting. As part of my due diligence I was talking to a lot of people that were either working or worked at Amazon in the past and one comment stood out for me. It was on the lines of:

“Usually every vendor has its own coded values and principles but you often just read them when you join the company and you forget about those. At Amazon it’s different: you live and breathe every day the Amazon Leadership Principles".

It couldn’t have been more true. The LPs are front and center. They dictate what you do, how you do it and, ultimately, they define the metric of your success at Amazon.

Another interesting aspect of working at Amazon is the public communication posture. I will admit that this was my biggest concern when I joined AWS because you often hear stories from the outside of “you need to erase all of your social media accounts” or “you need to stop blogging” and those sorts of things. Well, if nothing, this blog is a testament that the rumors you hear are highly exaggerated. There are indeed rules you need to follow but nothing mind-blowing to be fair. Most of them are common sense and standard social media best practices at many large organizations. Here they just take them seriously. I will concede that if you spend your day trolling people on Twitter your social media activity may need to adapt a bit. I am actually enjoying this part honestly and it’s helping me being less of a jerk on social media than I was before.

Last but not least on culture, I think it’s fair to say that I have never seen an organization so obsessed about customers. Granted this is not a secret, you can read it everywhere (including in the Leadership Principles). But trust me, the first time you get to hear things like “we think we should go meet with customer XYZ to optimize their deployment because there are savings we can probably suggest” you do really feel you are on candid camera. Customer obsession, for real.

The Solutions Architect role

In general, life (in the field) at a service company is fundamentally different than what life (in the field) looks like at a hardware or software vendor. The way a customer buys, the way you optimize, the way you help them. I am indeed learning a ton. In a Solutions Architect role you breathe this day in, day out.

One other concern I had when I joined AWS (other than the communication posture) was that I was going back to a field role in Italy (that is, not Silicon Valley). The reality is that regardless of the customers I have been working with so far (small Vs. big, mature Vs. less mature in terms of cloud adoption, etc.) I am learning a lot in every single interaction with them. I get to see the whole spectrum both in terms of size as well as in terms of use cases and complexity. I am loving it to the point that I am volunteering to sign up for a 5-hour drive to deliver a first call deck.

Being involved in the full spectrum of the use cases also allows me to not only see the traditional lift & shift scenarios (e.g. “I have 1.674 VMs in my data centers and I would like to move them to 1.674 instances on AWS”) but it also allows me to see what I consider the most interesting aspects associated to business outcomes and use cases. Forget VMs (and containers to an extent), I am building a customer demo as I type this to take clicks from the IoTbutton, send data to an object storage in CSV format, query the object storage with SQL syntax and visualize these data in a pie chart. I have done this in 4 hours. And only because I know nothing, yet, about this stuff. Someone that know better than me about this could have done it in 20 minutes.

Sure, for most this sounds like the new normal already but for someone that has spent his life on infrastructure related things this is literally jaw dropping when you think how much time (and money) this could save customers.

Which brings me to (IMO) the most interesting part of this blog post. Where am I spending the majority of my energies? What’s the role of a Solutions Architect at AWS? What is the most difficult part of the job? Where do you insist to try to get better in what you are doing? In other words, what does AWS pay you for?

The SA is one of the many functions inside AWS. SAs typically operate in a couple of dimensions:

  • they tend to have a long term working relationship with customers to architect and optimize their deployments on AWS in a 1:1 setting.
  • they contribute to generate content in the form of blogs, solutions, documentation as well as presenting at AWS and industry event in a 1:many setting.

I personally found the second dimension to be the easiest (relatively speaking). I have already done some of these things at AWS Summits and other industry events. You typically focus on an area of expertise and you deliver.

The first dimension is what I found more challenging and, frankly, the most interesting part of my job. I have broken this down into three distinct challenges/tasks that you have to carry on in parallel:

  • You get to know all of the AWS services. Before joining AWS I thought this was the most difficult challenge. After joining AWS, I figured this was the easiest part (again, relatively speaking). Don’t get me wrong, it’s a lot of work learning all the services, it’s a moving target and you will never be a guru on all of them. The challenge here is to know as much as possible of all of them.
  • In many situations you have to work backwards from the customer’s needs and translate their business objectives into a meaningful architecture that can deliver the results. This isn’t so much of a problem when the need is “I have 1.674 VMs in my data centers and I would like to move them to 1.674 instances on AWS”. But it is a challenge when the need is expressed in business terms such as “I need to do predictive maintenance on my panel bender line of products” or “I want to build a 3D map of my plants to offer training without having employees come on-site”. This is quite a challenging mental task because, among the many difficulties, it requires a good understanding of the customer’s business to actually understand (or better, anticipate proactively) the use case being discussed.
  • The third and possibly most difficult part is this though: once you get a good understanding of the services portfolio, once you get a good understanding of the use case, which one of the potential many combinations of services do you use to deliver the best solution to the customer? You will find out that there is an (almost) infinite way to build a solution but, in the end, there are only a handful of different combinations of services that make sense in a given situation. There are 5 dimensions that you usually need to consider when designing a solution: operation (you want the architecture to be easy to maintain and easy to evolve), security (you want the architecture to be secure), reliability (you want the architecture to be reliable and avoid single point of failures), performance (you want the architecture to be fast) and costs (you want the architecture to be as cost-effective as possible). It is not by chance that these aspects are the foundation pillars of the AWS Well Architected Framework. Finding the balance among all these aspects is key and possibly the most challenging (and interesting) task for any Solutions Architect. The other reason for which this is challenging is because it builds on top of #1 and #2: it assumes you have a good understanding of all of the services (perhaps the one you don’t know well and fail to consider is the one that would be the best suited) and it assumes you get a good understanding of the use case and the business needs of the customer.

Conclusions

All in all, I couldn’t be happier about my move. I am on track to achieve what I set myself I wanted to achieve and I am enjoying every minute of this ride. I don’t want to repeat myself but I left my previous company to join AWS and told my manager I was doing so to do a “Cloud MBA”. This is exactly what turned out to be.

The only suggestion I have is that you spend some time on this link here as it may open a world for you as it did for me: https://aws.amazon.com/careers/.

Massimo.