5 Must Read White Papers to Crack Cloud Solution Architect Interview

Let's face it there is no defined path to become a Solution Architect. A very organic and ideal way is to start as an application developer, then become a senior software engineer, to module lead to team lead, and then become an Application architect, and if still, you have gas left you to become a solution architect.

This approach does not work because of numerous reasons

1. You will not be part of the same company
2. Most likely you will not have full visibility of the entire architecture
3. You are a jack of all treads and master of none
4. You are a master of the frontend ( You were Jquery hero but no one is seeing that movie anymore) and knew little about the back end or the other way around
5. You are an Application Developer ( The creator, the person who always have some update that others understand very little but value the most), you don't need to know how networking is happening or DB sync is not working
6. You have been a good networking engineer or you know how the Deployment works but you have never developed production code so you are stuck

You can be in any of the above situations, and chances are you are sitting for an interview maybe for a new client in your organization or a new job, and you know you will be tested in few BUZZWORDS. Like Cloud Native, Cloud Agonistics, Micro Service, Containerization, Server Less, TechOps DevSecOps. This is an ocean and you know the interviewer can ask you from any of these areas, in this case, the below white papers can be your saviors.

1 .https://12factor.net/

All the interviewers are going to give you a chance to explain about your latest experience you should be able to reference your present architecture stack with the 12-factor (If not 12 at least mention 3 to 4) design principle. These principles are basically followed to some extent in every project but if you mention your project implementation in reference to these factors things become a lot more cohesive.

EX: As part of the 12-factor design principle we keep all the config related files outside the Active CI/CD pipeline. These files are encrypted and stored in secured paramstores and decrypted in realtime to point to different environments and services.

2.The 6 R’s”: 6 Application Migration Strategies

Even though we are talking about a lot of Cloud Native still we are having a lot of migration projects. The above white paper clearly mentions all the principles in a very practical way. Even though it is AWS centric

1.Re-host

2. Re-platform (Referred to as “lift, tinker, and shift.”)

3.Re-factor / Re-architect

4.Re-purchase

5.Retire

6.Retain (Referred to as re-visit.)

A walkthrough of this paper can give you a solid understanding of how to handle any migration project. In my practical experience migration project can give you a surprise in terms of its challenges. All the so-called export-import tools and application discovery tools work in a very minimalistic way, so be very careful when you tell something that“ We used VM export to build the servers in Cloud” — — you can be caught off guard

3.https://microservices.io/

Enter the bible, this is strictly for developers and some time will be too much to grasp.

A few questions you will always be asked, (for some time forget about the interview and think of how it was implemented in your last system) are

How to decompose the application into services?

How to maintain data consistency?

How to build queries that spans across multiple services?

Few concepts like Event Sourcing and Transaction Log Tailing are really really important for any architect to sustain in their jobs.

Event Sourcing — The key funds here are each state change is persisted as an event object and broadcasted in an event bus and appropriate subscriber responds to the event and updates its own state.

You can reference this concept like, once the consumer Lambda gets a message in SQS it updated the state of the object in DynamoDB and send an event in SNS which other services have subscribed to. These services then update their state.

You should check out of the comments, some awesome discussion takes place here.

4.Micro Service Reference architecture by Nginx

Nginx is still a market leader while choosing proxy and they provide some fantastic resources in this white paper, the circuit breaker pattern is something which you can explain in more detail in the context of your present project implementation.

When the approximate message count (In cloudwatch dashboard )in Dead Letter queue is more than 5, an alarm is going to get triggered which changes the parameter in the parameter store which was storing the consumer API gateway endpoint to a static page

5. https://martinfowler.com/

The last one is pretty obvious. This is one of my favorites and it basically hits the nail on the head on the first line that there is no defined definition of this type of architecture, but it has some specific attributes

i)decentralized control of language and data

ii) Automated deployment

iii) Intelligence in the endpoints

and I will all one more point to this is

iv) Managed Infrastructure

Lastly while all the above are fantastic resources I believe evolutionary architecture is the best practice when you start with any cloud-native implementation. Few things which are the key concern for the Architectes will be

1. Micro Service Observability and tracing
2. State management and reconciliation

Other critical things like infrastructure, deployment automation, service discovery, network, and security come as part of the managed service offerings by different cloud providers.

Remember the Interviewer is also on the same boat as you, the boat of evolution so as long as you are able to convenience him that you are aware but the worst design pattern to avoid you should be good.

Some additional references

Building Microservices Applications on Microsoft Azure Designing, Developing, Deploying, and…

This blog was originally posted in https://www.techcloudonline.com/2020/07/07/5-must-read-white-papers-for-solution-architect-interview/