Written by Sergio Flores

Photo by Hanna Morris on Unsplash

I have been developing software professionally for over 20 years now, and you can trust me when I tell you that my experiences in the field have given me ample opportunity to develop strong opinions on various topics that come up in software engineering.

So, today I’d like to share with you my 5 cloud architecture laws distilled from both the good and bad projects I’ve been involved with…and an extra bonus law which is controversial.

Let’s look at them first, and then explain them away:

You shall not be TOO committed to a very specific vendor product.
You shall not go crazy using NPM modules.
You shall design for the future, and implement for the now.
You shall take cybersecurity seriously from day one.
You shall design for the most scalability and portability that you can.
Bonus Law (Read till the end!).

1. You shall not be TOO committed to a very specific vendor product. The story goes like this: We have a brand new project to create, we’re thinking about the possible avenues of implementation and while we’re doing this investigation, we come across a bunch of shiny tools that are offered to us, promising to make our life easier, our projects faster, better, safer… but generally just easier, and therefore, faster to ship, with less effort involved.

   That’s all well and good, however, you may find that your lack of experience with said new tool might make you blind to nuances, operational details and implementation shortcomings specific to your project, that will only show up months or sometimes even years later, and by then, you’ll be fully committed to the tool, and unable or unwilling to execute a change, and so you’ll be suffering forever from whatever issues had arisen.

   For example, an external system forces you to use their own database, and you later find that modifying the schema is not viable and you end up with duplicate information that has to be maintained eternally, or a data tool that uses a very expedite format to produce faster simple queries, turns out to be utterly incapable of producing complex queries…which you didn’t fully need when you started out, but you need now, and now you need another data system and move data back and forth between the two forever. You get the idea. Now, what’s the best approach to avoid this pitfall? It’s certainly impractical to fully learn the details of every new tool, so instead, what I do, is:

   1. Stick as much as possible to tried and true tools, even if they’re not exciting at all. Our business is not enjoying new software, but getting things working, and make sure they keep working while everybody goes home to their family over the weekend. Put too much trust in the newest of the new and you’ll find yourself pulling all nighters on a Saturday more often than you’d like.

   2. Do consider new tools, and if promising, give them a limited space to operate in the solution, such that you can balance your risks/benefits ratio. Keep in mind however, that sometimes very new tools that look promising don’t make it in the long run.

2. You shall not go crazy using NPM modules. I know, it’s tempting. You’re doing this cute little Node app, and you need to do X, and well, why reinvent the wheel if somebody, somewhere, has already published a module that solves your problem, just an install away… well, let me share with you 3 words on that: “Supply Chain Attack”.

   In case you don’t know what that is, that’s when a given public module repo gets compromised by a hacker, or worse, when a malicious actor willingly and intentionally creates it from the beginning with the express purpose of carrying out an exploit, and you’ll get it right inside your privileged execution containers, with the full authority of the user under which they’re running, and depending on your circumstances, that could turn out to be anything from a mild annoyance, to a full blown emergency crisis.

   Ok, so how do we avoid this? What I do is take good long look at all the modules we could use, and decide if we really really reaaaaaaallly need them or we can duplicate the functionality either by hand coding it or by using available, easy to review source code. Will this add time to your development project? Maybe, but it will spare you from a lot more time explaining how the company’s company list appeared on the dark web.

3. You shall design for the future, and implement for the now. What this means, is that, when designing the solution, you should take into consideration everything you know about the present and expected future requirements and incorporate this knowledge into the planned behaviors and components of the architecture. Of course, you cannot plan for the things that you don’t know, so no need to obsess over “imaginary” concerns that may or may not happen, but with some experience, you’ll be able to guesstimate what things may come up in the future, even if they don’t seem likely right now.

   Once you have that design ready and documented, what you’ll do is take away anything that you don’t need in the immediate future and focus on implementing just what you need to get working right now. This approach helps to balance speed of execution against long term technical debt, making for a far more ordered future development path.

4. You shall take cybersecurity seriously from day one. Often, in the pursuit of faster deployment, we may be prone to cut corners on constraints, input assumptions, sanity checks and other typical defense measures, thinking that this will only be a problem much later when the product reaches a lot of users. And in general, you’d be correct on that assumption, but what you might find out, is that when you do reach that number of users, sometimes, in a surprisingly fast way, the vulnerabilities haven’t been corrected, due to having to work on a never-ending set of new features or bug corrections, and then you get hit by a surprise attack that catches you totally unprepared.

   Rather, the best practice here, is to incorporate that preparedness from the start as a standard operating procedure, such that, you don’t even have to think or worry about it later, because it’s already done. There’s no guarantees anyway, but the likelihood that you’ll be sucker-punched will be drastically reduced.

5. You shall design for the most scalability and portability that you can. This means putting some effort into thinking how can you start with the smallest, cheapest possible deployment, and how will you enlarge it to larger workloads as easily as possible, while keeping operational costs as low as you can. The specifics will depend on your particular implementation, so the important thing is the principle, and commit to make this effort right from the get go. Same with portability. It’s easier to just use whatever is at hand or your personal preference, but doing as much as possible to keep your deployment movable between providers will allow you future flexibility in case you find yourself some day needing a change.

And, finally, my own personal law, as a bonus to you, though some people find it controversial.

6. You shall use stored procedures extensively. Ok, hear me out on this one. There’s a reason why SQL databases are programmable, otherwise they would just be files, and that reason has to do with performance and security. In other words, it’s more performant to pack a bunch of code into a procedure, than sending each individual SQL statement through a connection. Sure, you can use a prepared statement, but when using procedures, you can also control the security access of the connected user.

   So, instead of sending a raw “SELECT”, and having to grant the user with said permission on whatever tables are needed, you pack the instruction(s) into a stored procedure and grant “EXEC” on that to the user, so the user can never send a direct “SELECT” and can only carry out the tasks done by the procedure. Of course this means that you need to know SQL programming well (which I do) and it also means that you need to put more effort into designing and coding this aspect of the app.

   In general, I also stay away from ORM tools, because, yes, they make the beginning of your project easier and faster, but if your data needs are complex enough, eventually you’ll find yourself trapped into their very rigid way of doing things. So i’d rather learn SQL and be free and all powerful :)

Thank you for reading, I hope you have found this post useful and see you next time!

Are you interested in learning more about this technology or explore how could it be applied to your particular needs? Please send me a message using the form below, for a no-commitment, exploratory talk about your situation.