Before we start building anything, we have to give some thought to HOW we are going to build it. There’s a couple of principles here that are incredibly important to consider upfront to prevent unnecessary rework later.
So, what is import to us?
- Secure
- Scalable
- Highly Available
Secure Architecture
Hopefully this is an obvious one, but everything we do has to be secure. Cyber Attacks are a very real thing and having a solid security posture established early on is essential to being able to deter potential incidents. To be frank, you can never be 100% effective against cyber attacks as the landscape is constantly evolving, but you can make yourself a hard target and this will deter most opportunistic attacks.
Common questions I get asked at this point are – Why do we need to invest extra time and effort into security? We’re not even live yet! We’re too small, no one will care. Etc etc. The simple fact is that if you get attacked and worst case scenario, sensitive customer data is lost, the reputation damage will be crippling, let alone any financial costs incurred fixing and compensating affected users.
There are a few frameworks you should be looking into if you’ve not worked with Security By Design (SBD) before.
First, check out you governments own variant. For example, in the UK we have the National Cyber Security Center (NCSC) has some great guidance, of which the Saas principles here which are directly relevant to us.
Secondly, check out your cloud providers guidance. As you know, we will be using Azure for this stack, but all cloud porividers have similar docs available. Azure has starting guidance here for secure design, so check it out.
Scalable Architecture
When we talk about scaling, we are talking about both up and out, or horizontal and vertical. This means that depending on the type of load, we can scale to fit demand in an economic way.
Vertical scaling, or scaling up, is the act of adding more power to your server. This is best for dealing with requests that require lots of CPU or Ram to be able to process. Horizontal scaling, or scaling out is the act of adding another instance to your pool. This is better for dealing with a large volume of small requests.
It should be no surprise that as a business you will likely start small, with one or two core customers. As you grow though, you want your product to be able to grow with it, with at little effort on your part as possible. That’s where scalable architecture comes in.
Scalable architecture is more about understanding when you need to scale and what type of scalability you need and is often considered an infrastructure consideration. As we are wearing start up hats though, it’s likely you will be the developer, tester, devops and support so it is something we definitely care about!
For our start up, we will most likely be using so called ‘server less’ infrastructure. This is a relatively new type of cloud component that basically abstracts away all the details of the scaling, leaving you to only deal with the code. We’ll look into this in a lot more detail later but for now, check out the Microsoft docs again!
Highly Available Architecture
High availability is a bit of a must in today’s always on society. It is basically is the answer to the eternal challenge of 100% uptime. Now, to be very clear, the odds of any application having genuine 100% uptime is basically impossible, but we can do our best to get to the coveted 5 9s. (99.999% or 5.39 minutes downtime per year).
Part of this approach is called ‘Plan to Fail’. This is a relatively new concept which historically would have terrified a traditional business. In short, any part of our application should be able to fail and gracefully recover with no noticeable service interruption to the end user. It’s important to note, that Planning to Fail sounds like we’ve given up before we start, but in reality, we are embracing to hard truth that hardware fails and we need to have a plan in case it does. We are planning ahead so that when those things happen, they have minimal to no impact.
A lot of the choices in this space will be down to the Cloud provider, so here make sure you check out the docs specific to them. For Azure, head here.
Cloud vs On Premise
For the sake of clarity, On Premise is a reference to a physical piece of infrastructure you own and manage. Cloud is a reference to a piece of infrastructure you don’t own and are using someone else’s.
I won’t dive into this, because the choice is pretty clear – Cloud. This is purely down to cost. We can easily provision infrastructure as and when we need it, with a predictable monthly cost as an OPEX expense. On Premise would require a significant CAPEX expense for initial purchase as well as OPEX for ongoing maintenance on the boxes. As a start up where money is tight, Cloud is the viable option. There is nothing stopping us from moving to On Premise later if the business case was made, so avoid the upfront cost!
Containers Vs Serverless
Containers have several major pros for scaled architecture. They act as a single published unit of a code base, where everything that is required to make it run, is included in the package. This package can be deployed anywhere, as many times as it needs to be able to respond to the demand it encounters. You can provision a single host, ie. Server, and from that host put everything in the same host if you want to (for cost reduction) or scale out to huge numbers of hosts that have hardware tailored to the job at hand if needed. They are great for porting legacy code into a cloud server, as you can configure an environment to run in exactly the same way as an on premise (within reason) then simply redeploy to a container instance in the cloud.
Serverless equally have a lot of pros but in different ways. Being lightweight, they are great for event driven, stateless applications and microservices. Azure Functions (the Azure Serverless option) has built in bindings to support multiple connection streams, reducing redundant boilerplate code. They only charge when they’re running, which makes them cheap and they can automatically scale out in response to increased demand.
So when considering Containers vs Serverless, the question boils down to the level of control you want over the environment that your code is running in. Ultimately, a Serverless Architecture abstracts away all the infrastructure and allows developers to work on only the things they know and care about – the code. It’s worth noting though that they are designed to be light weight, which means they cant do complex extension of middle ware (they can but not recommended) and need to start up very quickly as any request could be considered ‘cold’ that is to say they are the first request to a new instance of the Function.
For a start up focussed on simplifying a needlessly complex domain, we are going to be build a simple set of models that are lightweight and reusable. We also don’t have a dedicated infrastructure or DevOps resource yet, so we increase risk by opting for something that could fail or require maintenance in a way that we can’t complete in house. For this reason, Serverless feels like the correct choice for us. As a caveat here, this is based on this particular use case, there are many reasons for a Start Up to pick Containers, or even something completely different if they want. The key for me as a Start Up is to minimise risk, so taking away as much responsibility as possible if a big thing when you potentially only have 1 or 2 employees to handle a quickly evolving and growing architectural landscape.
Masters Development 