What is a solutions architect?

In general, a solutions architect is a designer.  They are someone who has deep knowledge about how systems work, both in isolation and as part of a whole. When talking about AWS solution architects, this means they are very familiar with the AWS services that are required to create multi-tiered internet applications, internal business tools, analytical and big data pipelines, and much much more.

This familiarity doesn't necessarily mean they will know every odd detail about any particular service. But a good solutions architect should be able to explain how that service operates: in a bubble, with other services, what it can connect with, and what services could replace it by being similar in nature.

A solutions architect is also an eternal student. They should regularly research and stay up to date on what new services have been released. Being able to incorporate new knowledge and not being stuck to existing ideas is paramount for success in solutions architecture, and in much of life in general.

The overall goals of the solutions architect.

In general, our role as designers is to create robust systems that are able to handle unexpected events as gracefully as possible. This means that whenever we create something, it should be able to survive things like: system failures, being overloaded with too much traffic, and dealing with the unexpected as best as it can. 

Additionally, our job is not only to create systems that have these capabilities, but to do so around specific goals. Each project is different, and you will have multiple goals most of the time, but in general, you can boil them down to:

• Designing for cost
• Designing for speed / experience
• Designing for security
• Designing for fault tolerance
• Designing for availability

For example: You might be asked to create a solution, but to focus on making it as cost-effective as possible. Maybe you are working on a budget-constrained project, that won't get proper funding until the minimal viable product is ready.

Maybe after that MVP is prepared, and you have been granted that funding, you would be asked to redesign that solution so that users have the best possible experience. Reductions in load times, and ease of sign in being a priority.

After that, it is determined that we need to redesign once more for security, as our product is gaining traction, and we want to start dealing with compliance-related data.

A short time later you might be asked to resign again, but to focus instead on the fault tolerance of that data. Now that we have gone to so much trouble to gain the customers, we don't want their data to be lost in a failure of some sort.

And finally, you could be assigned to making the project available for a global market. To make sure that whenever somebody, anywhere in the world wants to access their data, they will be able to see it without timing out, or having to wait for a server to respond.

Even with just one project, you can see how the scope of need might change over time, and what you are designing for shifts as projects mature.

It is also important to notice that it's hard to design for all of these needs at once, especially when cost is considered high priority. 

What you will need to learn to become an associate solutions architect.

The well-architected framework.

Becoming an AWS solutions architect can take a lot of time and dedication. But it is very rewarding having the full understanding of how all the pieces of an architecture fit together. 

To start off, you will need to learn the fundamentals of the well-architected framework. This is a guide written by aws that helps to describe key concepts for designing and running workloads in the cloud. There are five pillars that make up the well-architected framework, and each of them will help you to create robust architectures.

I'll summarize the ideas quickly here, but if you want a more in-depth lecture please watch this course, it will go over everything in greater detail.

The first pillar is Operational Excellence: Its goal is to have you focused on running, monitoring, and designing your systems programmatically. This pillar wants you to create your infrastructure as code, meaning everything you build, do, and manage can be described through text.

This gives us the ability to repeat the things that work well, and roll back changes that do not. We also want to look for ways to improve our infrastructure, our code, whenever possible.

When learning about new systems and services, try to think about how we can codify those things, how we can work to continuously improve them, and how we can monitor those changes in the system.

The second pillar is Security: Its goal is to make you understand your responsibility when building architectures. We need to secure our environments as much as we can, because failure to do so can be catastrophic for both your users, and your company. 

This means having robust identification and authorization of any users that have access to data, or have power to change the underlying architectures. We also need to create ways to trace data access and data movement, as well as provide security both at rest, and in transit for our data.

The third pillar is Reliability: your designs and architectures should be able to function correctly and consistently through its entire lifecycle. This means we should be testing and understanding how the system recovers from failure, scaling events, and outages. 

These systems should be automated, as it will reduce downtime and remove human error from the equation as much as possible.

The fourth pillar is Performance Efficiency: You should be constantly looking for new ways to improve your systems. This means staying up to date on new technologies and services releases from AWS. 

You need to be able to determine when a served solution works better than a serverless solution. You will need to be able to understand when it's time to switch from one to the other, or when a combined approach might be beneficial.

And the final Pillar is Cost Optimization: Most people can build a solution that will technically complete the design specification of a project - however, they might have done so in a not so cost-effective way. 

Everyone, everywhere cares about cost. It might not be their number one priority, as explained earlier, but you should not be creating wasteful architecture. You should be able to measure the efficiency of your systems and determine if any change you make will cost more or less in the long run. Additionally, you should regularly return to old solutions and see if there have been any improvements or new services that can be retrofitted in to improve cost saving. 

As we go through the learning process of becoming an AWS solutions architect, try and keep in mind these five pillars. They are great guides in determining what you should look for in a service, in an architecture, and in the solutions you are building.

The AWS services

There are a few groups of services that you will need to learn about in order to speak fluently about AWS. You will also need to understand how these services fit together, and what paradigms they work well with.

The service can be group together by function and I think it's helpful to catalog them in your mind in the following way:

• Service that can do work on data
• Service that hold data
• Services that help catalog data
• Service that glue other services together ( by moving data or notify when data is ready to be processed)
• Service that provide security for your data
• And services that create the network for users to access that data.

There are now over 200 fully featured services that AWS offers. The good news is that as a solutions architect, you will in general only need to memorize about 20 very common ones, and 40 uncommon ones for your Associate level certification.  If you decide to really dive deep into AWS and want to work towards a professional certification - you will need to have deep knowledge of all the previous 60 and general knowledge of around 30 more. 

Many of the remaining services will have very niche use cases and are something you can look up and read more about as they become needed for those specific use cases.

In addition to just knowing the services, there are a few design patterns and workflows that are important to understand as a solutions architect:

• Multi-tiered applications
• Micro-services
• The serverless model
• Dev-ops workflows
• Big data / database analytics workflows.

Your goal is to be able to speak about the benefits and the trade-offs of each of these, recognize them within existing architecture, and be able to create new or novel variations of any of these themes.