Software Architecture: Micro-Services and Zero-Trust Systems

Software Architecture: Micro-Services and Zero-Trust Systems

When it comes to software development, even with all the tools and methods at our disposal, it is still far too common for teams to jump into development without taking a little time to draft a software architecture plan. Laziness, pressure and inexperience are the most common excuses for this behavior.

Any business that takes itself seriously should eliminate that risk of such behavior and incentivize its teams to think before they build.

When attempting to architect a software system, you need a methodology to guide you in the process. Otherwise you risk building an ad-hoc solution that later requires a costly refactoring effort. It is all too easy to overlook performance, scalability, security, internationalization.

The concept of micro-services can offer a helpful methodology to compartmentalizing software and think in terms of components. Whether you actually build micro-services or not, this way of looking at a software system can help determine how to separate components, what, if any, functionality is coupled together, or how you might evolve a system to plan for growth. 

For me, micro-service design also couples well with and complements zero-trust system design thinking. With zero-trust systems design, you build cyber-security protections into the components themselves rather than delegate them to the network or system perimeter or make the risky assumption that ‘some other component’ will handle cyber-security risks.

If you apply micro-services architecture methodology and a zero-trust design principle, you can have greater confidence in a system’s ability to scale, perform, and remain secure as it evolves. Remember, I’m not advocating necessarily for implementing micro-services and zero-trust architecture in every software project, I’m merely recommending it as a method for making architectural decisions about a given system. You may or may not need zero-trust, but it helps to spend a little time thinking about whether such a principle would add value. You may or may not need to deploy micro-service systems in the real-world, but if you can conceptualize a software system using micro-services, it may help you make better decisions about which components implement which features.