Site Overlay

Find out how Rapid Development with Serverless is like Lego!

Reading Time: 3 minutes

A Rapid Development approach leveraged through Serverless is not widely understood in the broader architecture community. Adrian Cockroft has produced really informative talks on the subject. This short six minute video is a great example of one:

So what is Rapid Development with Serverless and why as an Architect is it an important to understand it as a concept/option in comparison to traditional methods?

Serverless is like building with (interoperable) Lego Blocks

Adrian talks about how Cloud Providers have taken common industry patterns and needs such as gateways, compute, storage and have created Managed Services that cater for the needs of consuming teams. For example, in AWS, your serverless gateway option would be an API Gateway. For Serverless Compute you might have Lambda and for persistence you could have DynamoDB or Aurora. These Managed Services are the ‘lego blocks’. Within the Cloud Provider these blocks are highly interoperable, abstract in nature (you won’t know the inner workings) and usually highly configurable to your needs. You can aggregate these building blocks together to create higher order functions, i.e. your business application. A basic example of this would be an API Gateway Block integrated with a Lambda Function to run some logic that is integrated with DynamoDB for persistence.

Lego blocks describing rapid development on the ServerlessEdge

Get critical feedback earlier, faster and smarter!

While Adrian is correct in saying that a team could produce a working system within hours, we should examine this a little more deeply. The idea here is that Serverless teams have a bias for action in terms of being able to assemble their lego blocks very early on and by shaping their solutions much earlier than traditional teams, through rapid development. The serverless eco-system is geared towards rapid experimentation and feedback. Test and Release cycles can be short, as in literally minutes. And as there is no provisioned physical infrastructure (that the team owns), costs are generally accommodating and low. Serverless teams will favour a product mindset and be much more able to react and pivot to directional shifts from the business. Traditional cycles are not as accommodating to experimentation and rapid feedback driven approaches.

Embracing the Enabling Constraints

Serverless provides team’s with constraints that guide their designs and how they assemble their architectures. In traditional architecture approaches there may be investment in working out interoperability and compatibility with Open Source and COTS solutions. When embracing Serverless-First the enabling constraints simply speed up the decision making process and allow for rapid development. These constraints guide the serverless architecture patterns of which there are many, that teams can adopt.

In conclusion, the Rapid Development Approach using Serverless is based around providing teams access to useable building blocks built on principals of interoperability, abstraction, optimised ops and costs that is best leveraged in a continuous development style workflow. This workflow will change how the industry thinks sbout software and will ultimately help evolve it towards a Serverless-First industry.

Traditional v Rapid Development

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »
%d bloggers like this: