Many don't understand how to use a Rapid Development approach in Serverless. Even in the broader architecture community. Adrian Cockroft has produced excellent talks on the subject. This short six minute video is a great example of one:
What is Rapid Development with Serverless? And why as an Architect is it an important to understand it compared to traditional methods?
Serverless is like building with interoperable Lego Blocks
Adrian talks about Cloud Providers taking common industry patterns and needs, like ‘gateways’, compute, storage. And creating Managed Services that cater for the needs of teams. 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 are able to put these building blocks together for higher order functions eg. business application. You could use an API Gateway Block integrated with a Lambda Function to run logic. And you could integrate with DynamoDB for persistence.
Get feedback quickly
Adrian is correct. A team can produce a working system within hours. Let’s examine this more deeply. The idea is that Serverless teams have a bias for action. They put lego blocks together. And put solutions in place, through rapid development.
You need to understand that a serverless ecosystem 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 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. Serverless-First and 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.
The Rapid Development Approach using Serverless provides teams with access to useable building blocks. Teams can benefit from the principles of interoperability, abstraction, optimised ops and costs.
And they can leverage it in a continuous development style workflow. This workflow will change how the industry thinks about software. And will ultimately help evolve it towards a Serverless-First industry.
Traditional v Rapid Development
Top comments (0)