Serverless Craic Ep23 Top 8 Principles for Cloud Software Engineers

Serverless Craic from The Serverless Edge

Today, we decided we'd have a chat about the 8 principles or tenets for a high performance serverless first team.

1. 'Chase a business outcome or a KPI'

A team should know what business KPI they're working towards. You should be able to tap a person on the shoulder and have them tell you what they're working on. And what business impact the work they're doing is going to have. If the team says 'I don't know', then you run a Northstar workshop. After the Northstar workshop if nobody can think of a KPI then the next step is to ask if the team should be doing this work. It's not that they are a bad team. They are being asked to do the wrong stuff.

2. 'Be secure by design'

Don't do security afterwards. Bake it in from the start. It's everyone's job. It's such a difficult thing to retrofit. Use threat models and get it done early. Try to solve for what you can and what you know. Bake it into all your engineering practices. And bake it into your pipelines. Shift it all left and help to enable teams to be more secure. Security has a risk profile, if you don't do it right. And it can be an existential risk for the businesses if you don't have a secure solution.

3. 'Keep a high throughput of work'

That is borrowed from the DORA metrics in the 'Accelerate' book by Nicole Forsgren. This principle looks at high throughput, which is deployment frequency and lead time. For serverless teams, it is key to make changes fast and frequent. And always be learning and driving observability. As Charity Majors says, "speed is stability". The more frequently you do something, the more you deploy to production. You're actually improving your stability. You smooth out the pathways and the error conditions. And you bake it into your pipelines. Which means that you automate a lot of the stuff that could go wrong.

4. 'Reliably run, high stability system'

That's the other two DORA metrics of throughput and stability. A lot of discussions with test teams, QA and software engineers drive the need for investment in world class quality and testing capabilities/practices. If you're not stable, where's the gap? What scenarios and behaviours have you not covered? It drives the right evolution. When you look at three and four, you can't achieve any of them if you've got things in the middle. Or handoffs, or if you are dumping things over walls. It's about promoting ownership. To get elite scores, you need to know what you're doing and embrace that approach.

5. 'Rent or reuse with build as a final option'

How do you do that? Serverless! With Serverless and SaaS and our background you're used to going straight to the workspace. And with the FORESEE diagram, we find out what we are doing and it is coding. It's a mindset thing. It's back to knowing your business purpose. And then knowing your business KPIs. If you can achieve business outcomes without doing code you are at your most optimal. If you can leverage a SaaS offering that does what you need, that's probably the next thing. And finally you need to build following a serverless first mindset and approach. Using all the serviceful offerings and managed services.

6. 'Continuously optimise the total cost'

This is the best question to ask any team. Good teams will tell you how much their cloud costs are. But loads of teams have no idea. This is a great measure of a good team. They have a cost in mind. A good team will tell you the run cost. And a great team will tell you the total cost. But really good teams will get into a worst case development conversation about how much features cost. And how much revenue they're bringing in. In other words, how impactful they are to the business.

7. 'Build event driven via strong API's'

This sounds very easy. But from talking to Sam Dengler, nobody is doing this properly. We've been talking about this for 20 years. Proper integration is still a mystery to most people. It is about making sure you've got the right things in the right places. But also at the right size. And having things that are composable. It's about breaking things up into their smallest constituent parts. And change things as frequently as possible. I find that this one takes a lot of evolution and yields through different levels of complexity. And it takes time. You should always be thinking about it.

8. 'Build solutions that fit in their heads'.

This principle is borrowed from Dan North. In other words, don't build crazy systems that are too complicated. This has a nice nod towards Team Topologies and setting proper boundaries. We've seen teams become victims to crazy architectures. Where there's too much to fit in your head and the cognitive load breaks people. When we are getting teams going my manta is 'just enough design'. Some teams want to design everything up front and go into huge amounts of detail. But it is better to keep your world small. Focus on what you're doing today.

Serverless Craic from The Serverless Edge

theserverlessedge.com
@ServerlessEdge