Serverless Diary: A Frugal Architect’s Approach to Security
I. Introduction
“Security is not an end goal in software design, but a continuous mindset focussed on crafting secure solutions with purpose and precision” — Frugal Agile Architect
In my previous blogs, I discussed how an agile frugal architect can leverage cloud-native options to build fast, evolvable architectures without heavy upfront investments. This approach aligns well with modern product development principles focused on quick time-to-market and iterative improvements based on customer feedback.
However, one area that often demands significant upfront spending is security. Traditional thinking dictates implementing comprehensive security tools and processes from day one. But in today’s cloud era, does this rigid approach still make sense? As a frugal agile architect, I propose a more nuanced security strategy that balances protection with pragmatism.
II. The Frugal Agile Approach to Security
Some may raise eyebrows at the idea of a “frugal” approach to security. Let me be clear — I’m not advocating compromising your security posture or risk appetite. Those are determined by the size, scale, and regulatory landscape of your business.
What I’m proposing is introducing the dimensions of scope, time, and cost to your security Architecture Decisions without compromising on Quality and risk posture. Too often, we make sweeping security investments without considering how requirements will evolve as our products mature and user bases grow.
Apply the classic consultant’s triangle of scope, time, and cost dimension while balancing the act of making an appropriate Architecture decision within the current context of the organization and the product maturity.
For a new modern greenfield project on public cloud and PaaS platforms, investing heavily in expensive security tooling from day one may not be prudent. Your scope (user volumes, which are influenced by features) and time (product maturity) are limited initially. As these factors increase incrementally, so too should your security costs and capabilities.
The above graph depicts two paths for a new product launch of the initial MVP solution:
- The blue path requires upfront investments in cost, time, and expanded scope for procurement, integration, skills, and onboarding before any value is realized.
- The green path leverages existing cloud providers’ native capabilities to enable rapid time to market while deferring costs associated with procurement, integration, skills, and onboarding. These can be reevaluated later, potentially after a year, as the product delivers more features and matures.
The goal is the green path i.e. a linear relationship between scope, time, and cost — not an upfront spike in costs that may never be fully realized if the product fails to gain traction.
III. A Cloud-Native Security Solution
Let’s explore a real use case example. Say you’re building a new product on AWS cloud, MuleSoft CloudHub 2.0 (could be any iPaaS platform) along with other platforms, and need to protect against common OWASP vulnerabilities. The traditional approach would be implementing a third-party Web Application Firewall (WAF) solution like IMPERVA, CLOUDFLARE etc from the start.
But below Figure 1.3 is a cloud-native, pay-as-you-go alternative: Use AWS WAF in front of your MuleSoft APIs (or any other PaaS or custom solution). You can quickly spin up WAF, configure it, and start using it — no upfront costs, procurement delays, or adding complexity with another vendor platform.
Option 1 uses AWS ALB as the edge service, configured with AWS WAF, and utilizes private connectivity via AWS Transit Gateway to connect to the origin, i.e., MuleSoft APIs. Option 2 uses CloudFront with a custom header to connect to a custom origin, i.e., any application deployed on the cloud or on-premises.
This allows you to go to market quickly while deferring the decision to invest in a commercial WAF product until you have real data on user volumes, revenue streams, and long-term product viability. You avoid getting bogged down in too many moving parts early on.
“Imagine starting with a basic puzzle of 50 pieces. It’s manageable and straightforward. But as you increase the number of pieces to 1,000 and add intricate patterns, the puzzle becomes far more complex. Each piece needs to fit perfectly. The same is true in architecture — each new integration with a new platform increases complexity and needs to be handled carefully".
IV. Final Reflections
Key Takeaways:
1. Leverage your existing cloud and PaaS platforms’ native security capabilities first which already benefit from economies of scale — they are cost-effective and can defer the additional complexity of integrating yet another platform.
2. Security is critical, but it can be delivered iteratively as your product matures, rather than through heavy upfront spending. Consider context, a service initially launched with low volume and restricted to a specific type of users will have a different security posture than a heavily popular service with multiple users and features.
3. Evaluate Architecture decisions across the dimensions of cost, scope/requirements, and time-to-market — the consultant’s triangle. Optimize for agility early on.
As architects, our goal is realizing business value, not just checking security boxes. A balanced approach that implements secure-by-design principles while deferring major investments until you have real usage data is often sensible, especially for new products. Security is a journey, not a destination. Travel that journey pragmatically as a frugal agile architect, doing this more often you will realise a pleasant side effect of high adherence to the sustainability pillar of architecture.