Enable Developers to Adopt Cloud and Build the Future by Shifting Left

Looking to inspire broad cloud adoption and rapid transformation within your company? Finding ways to shift left so that product teams and app developers are in control of their cloud journey is an important step.

Shift left simply means making it possible for development teams to self service the cloud for building their applications. Said another way, it takes cloud engineering, enterprise architecture, and other governing bodies out of the loop of managing every effort that involves using the cloud. This is great for everyone because it means cloud and reliability engineering teams can focus of building and sustaining platforms and products while app teams manage the prioritization and development of their applications and infrastructure as part of their product development lifecycle.

Shift left has to be a thoughtful practice where cloud leaders are looking at the cloud like a product and making it simple for consumers of that product to use it.

In this post, I’ve compiled a few practical things you can do to enable app teams without breaking the security or reliability of your cloud platforms.

  1. Secure the perimeter. There are so many ways you can misconfigure the cloud and create a security issue or introduce a vulnerability. Designing platforms with the right perimeter will help you sleep better at night and proactively prevent misconfiguration or deployment of unapproved services.
  2. Implement monitoring and testing. If you can’t measure it, you can’t improve it. Building monitoring into cloud platforms that generate alerts and create useful metrics can help to identify and mitigate issues in real time. This is a great way to catch things that you think are covered in your platform policies and configurations, but are somehow averted. Testing also allows you to proactively identify issues and make sure changes don’t cause regressions in your security posture. Make sure every mistake is a lesson and opportunity to build more monitoring and testing into the system.
  3. Define infrastructure as code. By creating reusable code modules and pre-approved patterns teams can more easily adopt the cloud for their use cases and you can be assured that resources are configured to meet your companies regulatory, security, and risk requirements. Infrastructure as code also allows you to create opinionated patterns that can help drive safe and stable adoption of cloud services based on developer use cases. Great documentation of those patterns goes a long way toward adoption as well.
  4. Use CI/CD pipelines. Using pre-configured pipelines allows you to have a standard way of deploying code to your environment(s) and enables you to integrate other important features such as code quality scanning, security scanning, testing, secret detection, and more. It also enables you to take another important step…
  5. Limit access to the UI. By making sure all changes are made using infrastructure as code and pipelines you can further prevent misconfiguration and reduce drift between environments. Finding the right balance is important to ensure app developers still have access to the tools they need to be productive day-to-day.
  6. Create playgrounds. Establishing a safe space for learning and experimentation is critical to adoption and building a broader DevSecOps mindset. It gives people a place to build confidence and experiment rapidly to determine the viability of the cloud for their use cases.
  7. Teach. In addition to providing a place to play, app teams need support from cloud engineering to be successful. Simply handing over the keys to the car without teaching anyone to drive will result in wrecks or worse a failure to get people to want to learn to drive at all. Treat the cloud as a product you are providing to your developers and make sure that the right support is in place to drive cloud ROI and improve the probability of mass adoption. Find the right balance between documentation, live support, and abstracting cloud concepts away with automation so developers can focus on building the next great thing.
  8. Reduce the blast radius. Make sure that all users and service principals use the concept of least privilege for the role they play in your cloud ecosystem and scope those permissions to the services those users are responsible for managing. To the extent possible, it also helps to automate this as part of a self service platform or your pipelines to reduce administrative burden while also making requests more simple, standard, and auditable.
  9. Take advantage of metadata. Most services on major cloud platforms support tagging. Tags can be used to automate tasks, allow or prevent actions, measure cloud adoption, manage costs, and much more. Define a strategy that helps you meet your team’s goals.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: