Using serverless technology in enabling high performing software engineering teams
Photo by Grant Carver

Using serverless technology in enabling high performing software engineering teams

The engine that is a software development team is a complicated one that needs a deliberate plan during formation and constant tuning to maintain performance. The team dynamics are so imperative to get correct that I would believe this to be the cornerstone of success in any team - it's the lubricating oil that keeps the engine working. That being said there are ways that we can turbo-charge that engine to improve the output.

In the drive towards efficiency we need to remove as many obstacles as possible that provide any hindrance to the teams efforts. The arena of software engineering is ever evolving and progressing and the team is constantly needing to re-skill on newer technologies, languages, platforms, and frameworks. While I feel this is one of the most attractive aspects of being in an ICT field it definitely slows down output for periods where focus is on introduction the new technology in addition to the problem solution.

This is not a new problem and we have several ways of mitigating the process of introducing new technology. Unfortunately the new technology often introduces complexity into the product that ultimately increases the technical debt and the barrier of entry for any new team members.

An effective manner to address this is by reducing the problem scope for the team. By focusing their efforts on a smaller field they are enabled to improve output and often simplify design. This is where I see the beauty of serverless platforms and in particular isolated microservices in software engineering. They allow focused work on the business problem freeing up the load occupied before by the ancilliary solution requirements. This is much like what the virtual machine frameworks of the desktop arena (Java, .net) achieved to a degree - but in the cloud and in an amazingly flexible way.

This is by no means a silver bullet and their are many scenarios where this technology will not be a good fit. Also, it comes with it's own architectural and design paradigms that in themselves introduce complexity. We are now dealing with distributed systems and asynchronous communication patterns, and these are not simple problems in themselves. The way we can deal with this is by providing tooling and building blocks that engineers can use to abstract away the complexity and again focus on the business problems.

An effective implementation of this is Taylor Otwell's Laravel Vapor which enables developers to use the Laravel PHP framework as is, and deploy it in a serverless manner on AWS with very few changes at all. It is not a strictly native implementation of a serverless solution, but they gain all of the advantages the AWS serverless offerings (scaling, caching, CDN, deployment improvements) with little to no effort and can continue to focus on their problem domain without concern for the operations side of PHP hosting.

Another exciting area is the Serverless Application Repository on AWS. This now allows reuse of common implementation patterns in a modular fashion within a serverless solution. Again, we are providing the building blocks to ease design and implementation by engineers.

As these serverless offerings from the cloud providers improve we are going to see more and more ways that they are simplifying the use and interaction of their entire serverless bouquet. We are also seeing third party solutions that address the complexities of observability and communication in distributed systems. This provides us with effective means to improve the productivity and effectiveness of our software teams and reduce the load of ancilliary or supporting areas of the problem domain. We are also able to slowly start introducing these solutions in stages without a huge knock on effect on the existing systems. We can effectively start breaking up our monoliths and enable our teams to be even more effective.

To view or add a comment, sign in

More articles by Grant Carver

Others also viewed

Explore content categories