MASTERCLASS: TECHNICAL DUE DILIGENCE FOR START-UPS

An Introduction to Well-Architected Frameworks

Erance Magoro, Senior Start-up Solutions Architect at Amazon Web Services who oversees the South African Operations, spoke to us about the many challenges that start-ups face and how you can mitigate or eliminate these challenges using the AWS Well-Architected Tool.

AWS Well-Architected Framework

“It is a set of questions and design principles across the six pillars of psalm.”

Pillars and Lenses

Operating excellence
Security
Reliability
Performance
Optimisation of efficiency and cost
Suitability

Those pillars give you a sense of how well-architected you are through a set of questions that you will go through.

Design Principles

It is founded on six pillars. These are questions which you go through and the answers which we get back from the tool, either a feeling or specific pointers as to how well-architected you are.

The Rationale for AWS’s Well-Designed Framework

To drive better outcomes for customers who build and operate workloads in the cloud.
Most customers who build and run workloads in the cloud are unsure or do not know whether they are well architected or not.
It’s all good when you have an idea that you want to implement and it’s easy to focus mostly on the idea of getting the business value you want to offer implemented and released, especially when it comes to start-ups. Building your business as a setup where you focus more on getting quick results and offering them in the quickest and most affordable way possible is common.
It is easy to forget or overlook how well architected you are for the future and then to get yourself into a bit of trouble a few months down the line when you start scaling, getting more customers, and getting a higher bill because of a design principle that was overlooked in the beginning.
The well-designed reviews ensure that you take care of that proper research while we are building or in the initial stages so that you are set up for success in the future.
It offers ways to learn about the strategies and best practices for architecting in the cloud.
It also mentions your architecture using your well-architected framework.

The Well-Architected Lenses.

Concentrate on the industry you’re establishing for it.
You’ll have lenses for the type of application you’re building, which will tell you how well-architected you are for that specific application or workload.
It also gives you a way to improve your cloud architecture by addressing it.

Pillars of AWS Well-Architected Tool

Pillar of Operational Excellence

It gives you the ability to run and monitor your systems, and to deliver business value and continuously support your processes and procedures.
A lot of start-ups tend to build to get something running, and that is fine, but forget about how we are going to deploy changes. Are we going to be able to run them? I see the pipeline fast enough that we can deliver more going forward without having to go through a lot of additional work and potentially breaking what is currently working in our production.

Security Pillar

Crucial to any technology company.
There are people out there always trying to hack into systems trying to take advantage of other business’ publicly available points. We will address any security vulnerabilities that could assist in your blood work production.

Reliability Pillar

It concerns your system's ability to recover from any infrastructure or service failure.
It is quite common to have the feeling that everything will eventually fail in some way. You don't want to be running a technology company and then having your application go down globally because you have some that connect from continent to continent That doesn't mean you don't want a power outage in whatever you're hosting or working on to affect you.
Reliability demonstrates that your application is taken into account and continues to function in the face of external changes.

Performance Efficiency

● It is the ability to use computing resources efficiently to meet system requirements.
● The performance efficiency will help you see how you can address that particular issue in the AWS cloud.

Cost of the Optimisation Pillar

Costs are discussed.
Because we don't organize our workloads properly, it's all too easy to divide up a lot of expenses unnecessarily. This pillar will assist you in identifying any cost issues you may be experiencing.

Sustainability

It is concerned with how long your workload can be sustained in the midst of a crowd.
AWS has a shared responsibility model in which AWS is responsible for the cloud's sustainability, ensuring that our data is as organised and efficient as possible. We are utilizing event power as efficiently as possible in order to have the least amount of impact on the environment. To ensure that whatever you design, consumers consume as little as possible, so that we can all run efficiently.

Benefits

● Build and deploy faster.
● Lower or mitigate risks.
● Make informed decisions.
● Learn AWS best practices.

Getting Started with AWS Well-Architected Tool

To begin, we know from experience that if you complete this well-structured review, you will receive high-level business sponsorship. In other words, you could be running a large enough start-up with high-level decision-makers. <br>

It is critical to contact the leaders to ensure that they are all on the same page as you when it comes to ensuring the proper design of your system or application. <br>

Second, make certain that we have the appropriate people in the room when conducting this review.

Third, take a collaborative approach or be collaborative

QUESTIONS & ANSWERS

Q: Have hackers been able to penetrate AWS?

Erance: There have been incidents of accounts being hacked and it's always been around, forgetting to encrypt your data. Leaving your data with public access because you know in this instance AWS cannot automatically say lockdown this data. It remains the responsibility of the customer to ensure that all the security concerns are taken care of in the cloud, so encrypting your data, ensuring you have tight access control and you have got all the security due diligence done beforehand. AWS has a shared responsibility model when it comes to security. So, AWS will go and secure the infrastructure, secure the network where the communication will be going into the AWS cloud through, and your responsibility is to ensure that within your AWS account you are well architected for security. If for instance somebody hacks in your account, the question is if that hacking is based on the way you architected? Are you encrypting your data? Or are you ensuring that there are tight access controls? Did you share your password with somebody? Did you enable multi-factor authorisation? And so forth. The responsibility lies with the customer or you as the person deploying your infrastructure.

Q: How do you know when you are ready for a technical due diligence intelligence phase?

Erance: The aim is to ensure that you are building at the right way from the beginning. We encourage our customers to take on it from the first day before you start building, as you are designing your workload, having the approach of designing for success in the beginning. Do ensuring that your design components you have are secured and whatever services you are deploying both for scale are built for resilience and that you are well-architected from the beginning. We do understand that some companies or some start-ups have already been in the journey, and they have a lot of stuff running out there it is also now so that it is still the right time to go through what you currently have running and doing the due diligence. It's never too early so it's more advisable to do it right from the beginning as it is a foundation which you are building on. It’s better to ensure that it’s strong and well set up from the beginning rather than having to pay for it later on.

Q: Are there any chances of me piling my work and all the processes that I am going to be using on building? If I save now will I still be able to find them after 3 years?

Henri: The tool is designed around workloads, in other words you have existing workloads. If you are still in the market fit analysis stage, in other words, whatever you will build to solve your customer’s problems. Then maybe just read the guide but don't make the tool your emphasis at that point. That is frankly too early you definitely want to then leverage tools that you get from AWS activates such as Build-on Templates, in other words templates that will help you. Let's just say lunch web application, blockchain environment etc and you get that in the activate console. So from day one the focus absolutely has to be to end customer and validating if there is a need from the customer, as supposed to getting analytics on how the security that technical stuff will work so I would really like to encourage that rather focus initially on the customer and then work that was from that point just add in there.

Q: What is the best way for a founder that doesn't have IT or developing skills to interact with the development that’s creating the software for them?

Henri: When you get started here as a start-up by definition cannot pay salaries. So the best way to interact with developers is to go into for example an AWS user group, there’s quite few, a lol. Then do your first sale pitch to the developer, set up a partnership agreement, make it that you’re a joint founder and now you're a team that's building on behalf of your customers and what you do is jointly write down what is that problem solving and that's called purify-q mechanism. So, before you get building and all that stuff of course if you are already engaged with a technical term that's giving you offers for engaged with technical terms that's giving you office for solutions. I would highly recommend looking at a business engagement approach, in other words don't think about the service and the tech underlying think about step functions. Which is a function for a service from AWS which is how Naked Insurance got started when I met them in very early stage. They just used Lambda to spin up their services and all they do as a team is talk about the customer’s processes and procedure as opposed to which database to use. There are fourteen different kind of databases and the kind of tech that you use is definitely going to make an impact and how you can scale and also the cost run rate that you're going to have on your initial platform. So it's nice to talk when water falls, wire frames and documents all that into functional specs but I would highly recommend focus all the energy back again into the customer view and if you can get to pitch to a developer to join you as a team, a co-founder when you are putting yourself on a great trajectory going forward. Otherwise it is going to be a business discussion vs a technical output and the certainly different ways to solve the same problem.