Use Isolated Environments

One of the recommended best practices for cloud computing is to use isolated cloud accounts, subscriptions or projects. This approach ensures that workloads, data, environments and services are segregated. Separating workloads into their product teams, business units or similar reduces security risks and the impact on change. Consider an application experiencing a surge in traffic, this spike should not affect the performance of other applications. Similarly, applications with differing risk profiles or scalability requirements should not impact each other's security or financial footprint.Adopting isolated environments helps mitigate these issues, leading to a more robust and efficient way for teams to operate their services.
‍
Recommended Resources
• Appvia Cloud Landing Zones for Azure | Product >
• Start your Azure Well-Architected Assessment | Product >
• Appvia Cloud Landing Zones for AWS | Product >
• Start your AWS Well-Architected Assessment | Product >
• Sharing cloud accounts? Think again. | Social >
• 5 solutions on how to isolate your environments in AWS | Social >
‍• How to design isolated resource environments in AWS | Social >

Create Self-service with Guardrails

Developer self-service streamlines infrastructure management, environment management, application deployments, and third-party integrations, boosting efficiency. The objective is to enable developers to deliver features and software more effectively. Making self-service components secure by default means that Developers can focus on delivery without having to up skill or worry about the security details. Allowing Developers to utilise platform capabilities whilst enforcing security checks throughout the self-service experience maintains a healthy security stance without compromising on speed or quality.
‍
Recommended Resources
• Wayfinder: Developer Self-service infrastructure with complete control | Product >
• Why developer self-service is the key to cloud innovation | Free eBook >
• DevOps Initiatives Will Fail Without Developer Self-Service | Free eBook >
• Unlocking Efficiency with Developer Self-Service | Social >

Use Cloud Patterns

To ensure product success, it's crucial not only to turn a profit but also to maintain a healthy gross margin. Empowering product teams with direct control over operational costs is essential. A platform should offer transparency in costs and enable teams to reduce expenses by eliminating unused infrastructure, downsizing during off-peak times, right-sizing instances, and using more cost-effective infrastructure. Without this cost control, teams may struggle to implement effective cost-saving strategies.
‍
Recommended Resources
• Appvia Cloud Landing Zones for Azure | Product >
• Start your Azure Well-Architected Assessment | Product >
• Appvia Cloud Landing Zones for AWS | Product >
• Start your AWS Well-Architected Assessment | Product >
• Differences between AWS and Azure Well-Architected Frameworks | Social >
• 5 Cloud Pattern capabilities you can leverage from Cloud Providers | Social >

Product teams control platform changes

Product teams should be empowered to manage operational changes to their cloud infrastructure, with the ability to implement approved updates at times that are most convenient for their end users and during off-peak periods. This can be in the form of security patches, moving to the latest version of libraries, upgrading the cloud resource their applications depend on or applying platform improvements associated with their workload infrastructure.  Releases of new components, configuration changes or amendments to existing versions of self-service artefacts should have gone through rigorous testing phases that validate the security, configuration and upgrade paths. These changes should then be pushed out so development teams can take accountability for applying and testing them as part of their application lifecycle.
‍
Recommended Resources
• How to avoid day 2 challenges | Social >

Have an API Contract

To provide a service that can be relied on, there has to be an API contract in place that gives teams a way of testing and validating their changes before applying them. When Developers consume self-service components they must meet the requirements and adhere to the API specification. If specific required or optional configurations differ between environments, then these can be tested and validated through the application lifecycle appropriately. Changes to self-service components should result in new versions that attempt to maintain full backward compatibility without causing any breaking changes. This approach will provide teams with a way to test, iterate, and deploy to production without depending on additional resources or specialist skills in their team.

Listen to your Developers

A Developer Platform, like any product, should be driven by its users, meet expectations and provide value. Developers need to be involved in shaping features of the product and validate the ways of working that help optimise their experience. They should be involved in prioritising the roadmap and providing constant feedback to help improve the platform. Developer adoption of the platform is a key measure of success. Traction will increase if it is meeting the needs of the Developers. Mandating a platform, however, doesn’t provide a good insight into how easy the platform is to adopt and whether it is enabling Developers in the right way.