As cloud adoption has become mainstream, we've seen a pattern in the challenges companies run into on their journey. Perhaps they've got a few apps in the cloud, but adding new ones doesn't seem to go much faster. Costs are higher than expected. Sure, they're in the cloud - but the platform doesn't feel truly operational, and they're not nearly as far along as they thought they'd be.
Who builds and maintain the platform?
The first discussion point we see typically regards who should own the platform.
Traditional infrastructure and operations teams struggle to transform their skills for the cloud. Quite a lot of architecture knowledge and programming skills are required, especially if you're going to take full advantage of infrastructure as code.
Due to this, lead developers often end up building the first cloud platforms in an organization. They get it working and go back to writing code that delivers business value. The platform works for them in the short-term, but longer term concerns - robustness, cost of ownership, scale, even security - can be overlooked. There is simply too much for a developer to know to expect them to be able to do all of this well. To make it worse, when it comes time to add another application to the cloud, another development team needs to learn.
The solution we recommend is to establish Platform Engineering. These teams and skills are nascent in organizations, and we see them as the way of the future. Platform Engineering groups have depth in cloud and DevOps skills to build infrastructure in a repeatable way and create a positive developer experience that enables business innovation. They carry the cognitive load of ever-changing cloud technologies and how to make them perform well for the full organization.
Platform architecture that supports innovation
The next, and perhaps obvious, question we receive is "How should the platform be built?"
nvisia's position is that the best way to build a platform that can support all your different development teams is to use a hub-and-spoke architecture, with landing zones at the spokes. Common cloud services live at the hub and support all teams. Within their own landing zones, the teams can innovate.
We think it's important that this is built through infrastructure-as-code. (We like Terraform, but other options exist.) Our reasons are super simple: there is just far too much turnover in today's workforce not to document how your cloud platform is built, and the only documentation that stays current is code itself. There are other benefits to IaC, of course, but this one hits home.
Platform engineering teams go beyond the cloud infrastructure to provide common tooling and middleware. We see Kubernetes as an extremely valuable component to have available for teams in their landing zone. Tack on a DevOps pipeline that delivers Docker containers to that Kubernetes cluster, and you're set. The devil is in the details, of course.
How nvisia approaches these initiatives
We've got a DevOps mindset here, and like all good DevOps people, we think it's silly to build the same things over and over again. So when we saw client after client needing the same thing, we automated it. Now, we are ready to offer a three-month service to build an Azure cloud platform with a hub-and-spoke architecture and Kubernetes in the landing zones, along with the Azure DevOps pipeline to deploy to it. It was built for highly-regulated enterprises, and ready to be fully operational. The three-month service includes customization of the platform and training for your teams. You keep the Terraform scripts when we're done.
To learn more about Digital Foundations, 
.
Interested in a little more technical detail on the recommendations? Check out our earlier blog post on Cloud Native DevOps.
Conclusion
Cloud adoption journeys are filled with promise and challenge. Look to build a strong Platform Engineering team to own the effort, rely on infrastructure as code, and move to a hub-and-spoke model to enable teams, without constraining them.