Stable. Secure. Resilient.

These days, users and stakeholders expect products to be stable, provide a high level of security out of the box, and remain resilient to issues that will inevitably arise.

Based on this important trio, I began reciting a mantra wherever I work with systems designers, security architects, software engineers, and network professionals. A simple mantra that reminds people how what they are designing and implementing has to be: Stable, Secure, and Resilient. SSR for short.

Stability gives both users and businesses the peace of mind that the products are mature and will provide the service they are either paying for, or bring revenue to the company that has built them.

Security is there to make sure data access, information flow, and data integrity is maintained, and what users expect to be true, remains so.

And finally, resilience. Without the ability to maintain services, and quickly bounce back after a problem, a product not only is less stable, but can become unusable very quickly, resulting in lost of trust for the users, and revenue for the business.

How do we make sure SSR is there? What are the things we need to focus on in order to make our products stable, secure, and resilient?

There are some important principles we can follow. These will maximize the chances of a stable product, help lower vulnerabilities and other security issues, and provide a solid foundation for resiliency. They are:

• Keep it simple
• Don’t reinvent the wheel, use known, proven technologies
• Architect for scale and redundancy
• Limit your options
• Reduce the sources of data

Let's jump into each one

Keep it simple

Simplicity, for the most part, guarantees security. The simpler a system is, the easier it is to maintain and patch. Simple designs allow for better ways to upgrade their parts and make sure that all elements are understood, known, and easier to assess if needed.

It is important to mention though, that until security can answer, in real-time, what data lives where, who has access to it, and how it is being used, even simple systems can lead to security horrors.

Don’t reinvent the wheel, use known, proven technologies

There are proven ways of doing things, from the architecture of systems, to the technology supporting the development and deployment of them. Don’t try to create something of your own just for the sake of saying you did it, stay with the things that work. Update and enhance, but always keeping stability and security in mind.

Architect for scale and redundancy

Your solution needs to work for one user or one connection and thousands of them. Factoring in earlier scalability will make sure that your solution will continue to work, regardless of how much use/growth it has. Same with redundancy, make sure you build a way to either have backup systems / elements / what-not, and the ability to switch between parts or revert to a previous working state fast, in case one part fails.

Architecting your solution this way will guarantee resiliency.

Limit your options

Create a restricted list of technologies and processes you can use to develop your solution. Doing this will help you keep in track with simplicity, the use of proven technology, and the ability to architect the solution better.

Reduce the sources of data

Lastly, and equally important, make sure your data always comes from a trusted source. Reduce where your solution / app / system can read data from, and who can send (and how) data to it. Always verify, and assume malicious intent. Reduce the sources of that.