About a year ago I first heard the dreaded acronym “MVC”. It was during a call about a potential project, and this contact kept namedropping it like Kanye or something – not that I knew what it meant at the time. I kept wondering how Model/View/Controller was so important to their deployment. Eventually I learned it stands for “Minimum Viable Cloud”.

I want to take whichever consultant came up with that concept, dip them in chocolate, and toss them into a bear preserve.

In the spring. Say around March or April.

I’ve been hearing it more frequently since then, and here’s what it means, why I think it is a stupendously terrible idea, and a better alternative.

Note that I don’t assume MVC is universally defined or understood – it seems to be more of a catchall term designed to assuage cloud fears while driving big consulting projects. The general consensus seems to be that you predefine and build your cloud environment, then shovel all your projects into it. Typically this is a single account (bye bye blasts radius management), with 1-3 virtual networks (dev/prod/???), and the full architecture built out like a single data center.

All the security groups, subnets, and other major structures are predefined. These deployments are more likely to have a bunch of virtual appliance versions of the same tools used on-premise. There is a lot of complex work to set up and isolate subnets and such, some minimal cloud-level IAM and alerting, and a lot of baggage carried over from existing operations.

It doesn’t work. Not for long.

MVC fundamentally breaks agility and reinforces bad old habits. Even if you try to design a ‘friendlier’ MVC deployemnt, it doesn’t scale and doesn’t offer the security benefits of a cloud-native approach. With MVC everything you deploy has to fit an established pattern.

Instead of fitting security to the project you are forced to fit the project to the security. Don’t interpret that statement as me saying security is a lower priority – it is an equal priority. The best security is when the parts are designed to cooperate and reinforce each other. You can’t do that with MVC. It is an anti-pattern.

MVC also typically results in many assets of differing security contexts sharing the same virtual network and cloud account/subscription/project. It is often selected because, at the start it looks easier to manage, but in the long term it becomes harder, as you struggle to deal with all those conflicting contexts and isolate everything out in an environment not designed for that type of isolation.

Instead follow the cloud-native pattern… which works for lift and shift as well as new builds.

  • In this approach the application and security architecture teams work together and design in parallel (ideally – you could add in security later, just not too late). You fit the security to the application. At the start there is a lot of learning new things, but over time you learn and build a library of relatively standard design patterns.
  • You deploy into a clean account/subscription/project each time if you can. This enables you to minimize the number of privileged users who need access to the cloud account and simplifies, overall, the configuration of the accounts. This approach helps you close in on immutable and indempotent deployments (for production – development environments are still more free-form).
  • You now have an isolated environment working within very defined constraints/definitions. This reduces complexity and is a bit of a security dream.
  • It does increase another kind of complexity: managing all these different environments. There are organizations managing thousands of cloud accounts today. Management shifts to automation, deployment pipelines, and maintaining security guardrails across accounts. The alternative is complexity within an account, often leading to conflicting and difficult-to-enforce security boundaries.

And that’s the key. I don’t claim managing cloud-native deployments is necessarily easier, but it shifts management in a direction that improves inherent security. You gain stronger security boundaries and tighten control, but in exchange you need to adopt automation and new management techniques and tooling.

MVC always fails over the long term. Always – you inevitably reach a point where too many things, across too many conflicting security contexts, are sharing a single implementation. It seems easier up front (and probably is, especially if you are new to the cloud), but sooner than you think you will need to make security compromises. It additionally inhibits your ability to properly design security for any individual project, because the applications are restricted to a pre-configured set of rules.

MVC usage correlates highly with ‘monoclouds’: stuffing everything into a single account with a small number of virtual networks. We also see some MVC deployments where they create a standard template and then deploy it into multiple accounts. Those aren’t quite as bad, but you still cannot fit security to the application and deployment.

This is a period of massive transition. Greater than corporate adoption of the Internet itself, because the cloud requires deeper reengineering of underlying architectures. This is an incredible opportunity to break out of constraints of the past which have inhibited security – especially backward-looking MVC and monoclouds.

Focus on education, automation, and tooling. Instead of building an MVC take a cloud project (ideally a new one) and “right fit” its security. Then take those lessons and move onto the next project. You will trade off getting all your sh** into the cloud as quickly as possible, but gain security and be able to move even more quickly over the long term.

Share: