Reliable, Scalable and Maintainable Applications — Software Architecture

Quiubole! I’m back, ant this time, I want to talk about some adult subjects, let’s talk about software architecture. I have some post related with this kind of subjects but they’re more like steps or specific models to implement, and yeah, it is good for developers or developers that want to learn more about architecture and follow their dream to become an architect, but the reality is, that, if you want to be a software architect, you’ll have more doubts than answers, you’ll take care of abstract and confuse issues and you need to provide a clear answer basing on that, that’s why I decided to bring this post to the table with the 3 principles of the architecture and let’s do it.

Problem

Development, that’s it, that’s the issue in our life as developers, the application is never the problem, how is that? Because you’ll never have any problems developing an application when this application will going to remains the same throught time, think about, if I create a software to increase the size of any picture and I’m the only user that consume the service I created, there will be at any time the need of updating it once the project is finished? of course not, but what happen if I just expose the service to the world? Well, things change a bit don’t you think?

I sent my application to production and made it public for everyone in the world, well, if I’m lucky enough, my application’s traffic will increase, I won’t be the only one using it, and what could happen if my page’s traffic started to increase by 5k new users per month? Could you see the issue?

My free AWS account for web hosting will turns crazy, my service will collapse because it will take more requests than it could process, the response time of my application for every request will be a mess, and I’m just talking about consequences in terms of usability, but there are many other issues that I’ll need to take care about

Way forward

Yes, few words back I said “you’ll have more doubts than answers” and all this catastrophic words, but actually, we have a way to get closer to the truth, to the solution, to happiness… When you’re developing an application, a project, you’ll need to do it with some words on your mind

Reliability, scalability and maintainability

The magic words, but, what is that mean? Well, that’s exactly what I was about to explain…

Reliability

What it means a software to be reliable? We can think about it a “a software capable enough to runs even when faults were present” Ah! it’s more understandable now right? But, because I know you, you little hacker, let’s be more specific, “a software capable enough to run even when reasonable faults were present” Aha! is it clear enough now? I think it is, but, why did I add the “reasonable” word on the explanation? Well, because this world has perfectionist people and they will try to patch every single possible threat, but no worries, it is a waste of time try to secure your application against a meteorite that impacts directly on your 5 redundant servers.

Hardware vs Software

We all know that everything can fail, a physical server can overheat, get disconnected. Software can throw exception for data parsing, data reading and writing, can install wrong drivers, have incompatibilities with OS updates or libraries, a lot of things can go wrong, trying to fix and anticipate every single possibility is impossible, that’s why we don’t ask you to do it.

Hardware can be less painful than software in this aspect, hardware issues (usually) are not related, that means, if a physical server stops working, that doesn’t means all server will stop working, and if you have a good physical strategy, like, redundancy, maintaince, good installations and all the good practices, it is complicated that it will scale to a really big issue. In the other hand, software has a lot of more relations and variability, that will make everything to fail, if one microservice just stops and 3 more microservices need to consume that service that just got down, well, it could be a mess, if one container showed an error that stops the application, all the pods or replicas will show the same, as you can see, it is complicated.

We all understand that is a complicated job and we all understand we’re not gods, that why, we only ask you to develop and design having this word on your mind, your application must run even when a fault were present, and I don’t mean it needs to run perfectly and have no consequences when a fault appears, I’m just saying, you need to handle that in the best possible way, trying to no get the service stops, or prevent data to gets corrupted, maybe you won’t be able to return the expected answer but at least, it didn’t destroy our system, some way to achieve this it’s by implement try/catch blocks, atomic operations, validating data, adding unit/integration/component/e2e tests, and more.

Scalability

Another concept that comes to ruins your life, what do I mean by this term? Well, it basically means “A software capable enough to grow along with its loads” Fantastic! But, that’s what we all do right? That’s why we all have jobs, there are few developers that works in new products or projects from scratch, the majority of us work in new features in an existing project or system, not all of us started to work in an application with ten active user and ended up in a 10,000 user application, that’s why, we need to understand that, scalability it’s more than just make it work, let’s put an example

Hardware

Problem:
For our resize image application, we can process images not bigger than
512 x 480 and can't increase the size more than 1080 x 720

Solution:
Upgrade our graphic card so our server won't explode trying to handle
this tremendous operation

Software

Problem:
Calculate and show metrics of the API usage is too expensive, it takes too
much time, and it is one of our most used pages, that makes users stop
watching the metrics and never noticed when they're run out of credits

Solution:
Metrics shouldn't need to be real time, users rarely visit the page every
time they consume the API, so, adding a cache system will increase the
speed in the response time

Could you see it? I didn’t need to recreate a new way to calculate the metrics and still made everyone happy, and maybe a future feature will require to add real time metrics because users want it, and scalability talks about, being able to implement the require changes for the growth data without having a huge mess, it complicated because I can’t give you clear solutions, I’ll keep talking about architecture in future posts to have better ideas of how to achieve this but, it will always has an abstraction level on the processes and solutions.

Maintainability

The last architecture principle, and we talked before about this subjects in other posts, it basically is “A software capable enough to be read it and interprete it by human software engineers” Remember, you code for humans and compile for machines, computers don’t need things like:

func main() {
  fmt.Println("Hello world!")
}

They need:

00010101011010101011010100100100100001001010001010000101011010100110100

That’s why we need to keep things simple, and by simple I mean, simple not easy. Complexity has two sides, the required complexity and the accidental complexity.

Required complexity is part of the problem or solution, creating a neural network from scratch, creating the math process it’s too complex but, you can’t just remove the complexity, it is complex by its nature, on the other hand, having bad naming on variable, methods and classes, infinite nested loops, huge files, bad designs, wrong models, all this things are accidents, or that’s what I like to think, this kind of things could be remove (at least the majority of them) by just paying attention and refactoring, if want to know more about this subject in particular you can visit my other posts:

Software Architecture — Make it clean
Micro-Services — Theory
[Arch] Design Patterns — Creational Patterns
Standardize Communication Data — Software Development

Thank you

for reading, I just wanted to introduce you the pillars of the software architecture, next architectural post, we’ll talk more about decisions in the data modeling, for now, that’s it for me, see you on the next one!