Technology plays an important role in complementing the cultural and working model practices that we discussed previously. They make the team more efficient with their work, leading to increased efficiency. Let’s discuss some ideas that you could consider adopting.
Right-size the teams based on the technology cognitive load they can handle
Cognitive load is the amount of working memory your brain uses to accomplish a task. Just like how heavy memory usage in the computer slows it down, teams’ performance can take a hit when they are burdened with a lot more than they can handle.
You might have also heard questions about how big a microservice should be. Where exactly should you draw the line when it comes to defining the responsibilities of a software team in a huge monolith or microservices-based application? These decisions should be driven by the cognitive load a team can efficiently handle. However, at the same time, the structure needs to be flexible to change. As a DevOps practitioner, it’s important to always be on the lookout for team burnouts and rapid expansion of technical landscapes. Operating a monolith in the early days might be manageable work, but it might not be when the application has been launched in multiple geographies around the world. At this point, specific areas of the monolith might have to be carved out as a separate service, owned by a dedicated team. What is essential is that a single team should own the entire life cycle of the service they manage, from ideation to production operations, and they should perform this role quite well, with full autonomy and ownership.
Invest in building abstractions that promote best practices
Creating Amazon RDS databases is not a differentiated task. Using these databases to extract value from data and demonstrating engineering excellence is.
If you leave the infrastructure life cycle management of such services to respective teams, there’s a high chance that every team in your organization might implement it a bit differently. Some might not enable encryption at rest, and others might not enforce SSL connection parameters. It could also be the case that organizations just getting started with AWS might want to ensure a minimum security posture in the cloud while the teams gain a better understanding of best practices. Services such as AWS Service Catalog can be very beneficial here. The platform teams could offer a ready-made catalog of packaged products to the end users by implementing and abstracting the implementationdetails in Service Catalog. The product in this case could be implemented with CloudFormation or Terraform scripts under the hood, two famous IaC solutions. The value streams need not bother aboutthe configuration specifics of these offerings from the platform team, but just use them as a service, just like they would do with any other SaaS product out there. These products could also adapt to the software environment they are being provisioned for. In production, they could enable backup retention and prevent accidental deletion, while in dev, they could enforce low-cost configurations.