I often am asked, “should I put a third party portal in front of my Azure or multi-cloud environment?” They ask for a good reason, they want to achieve control of their cloud environment and help their organization to make good decisions. It often comes from organizations who have a self-service portal in their on-premise environment and want to achieve the same ‘efficiencies’ in their cloud environment. There are a lot of reasons why people go down this route, but it is NOT a good idea. In fact, deploying a portal in front of your public cloud is a common anti-pattern that companies should avoid. Here are some of the reasons to avoid this approach.

1. Counter-Productive. The best way to judge a technology solution is by its fruits. Does it improve the business condition, interaction between teams, appropriate consumption strategies, and implementation of governance? The returns are that a portal strategy does not and in many cases worsens all of the above. The companies that have tried a portal strategy are leaving it in favor of more future-appropriate strategies that achieve the outcomes that better the state of the business.
2. Expense. The deployment of a third party portal in front of Azure or any multi-cloud environment will have a sizable expense. I’ve seen many companies build out expensive portals (many to the tune of $1 million+) to deploy VMs into their cloud environment only to back it out later.
3. Lock-in. The deployment of a third party portal locks you into a deployment technology that is complicated to remove. This is intentional by the providers and one of the many reasons you see almost EVERY cloud management provider has their own Cloud Management Platform (CMP). The majority of these are simply intended to lock you into a third party’s management ecosystem. In this case, beware of “free lunch”.
4. Efficiency. It might seem counter-intuitive, but having your requests flow through a self-service portal rather than use other methods of provisioning will be significantly more inefficient, both on the provisioning side, as well as AFTER provisioning. If our goal is to provide a highly efficient management environment, there are much better ways to optimize operations, both for the initial deployment, as well as release management. We think building provisioning tools as a way to speed up the deployment process, but in reality it typically ignores better approaches, like infrastructure-as-code, and doesn’t focus on where the real problems are, which is the configuration after initial provisioning.
5. Nobody Uses It. Well, perhaps not “nobody”, but the teams you really want to be part of your cloud strategy, certainly won’t. Let’s say you’re building software today. Are you building it on stand-alone Windows VMs? Not likely. You’re more likely building the software on containers, PaaS, serverless, SaaS, IoT services, or Big Data. None of these scenarios are well managed by a self-service portal and most developers are going to want to use an infrastructure/app-as-code approach. The reality is that most portals are built for a very legacy user base and completely ignore where most if the upcoming demand is coming from. If the goal is to partner with the application teams and help them achieve their objectives, a self-service portal totally misses the boat.
6. Innovation Curve. You will never be able to keep up with the innovation curve that exists within the public cloud providers and will spend most of your time playing catch-up. This means that instead of partnering with the business in engaging the cloud, you’ll be seen as a constant road-block to innovation. This is not a comfortable seat for the IT organization to be in, especially when it is trying to move from service provisioning to service enablement.

So, if I’m NOT doing a self-service portal, what should I do? The best approach is to make your public cloud providers largely read only and then use an infrastructure-as-code approach to provision all services.

This approach is paired with a GitHub repo (or another repo), release management, and excellent documentation that is available for all stakeholders. The approach works well when paired with an enablement team that can work with application groups and “show them how to fish”. The end goal is that every person provisioning services is using infrastructure-as-code, with certain controls applied there, and then policy applied at the control plane. This may seem challenging based on your current staff but I can assure you it is 100% achievable in small and enterprise organizations with the right leadership and messaging. In this model we see a much more mature and efficient operating environment, focused on protecting the company through tooling and enabling the organization to move fast when needed.

Nathan Lasnoski