In large organizations, authorization can be a very complex topic.
Almost always it is tightly constraint with strict compliance requirements, while at the same time
it is intricately tied to the user experience. Who hasn’t had the experience of trying to access a resource they need
for work only to be stumped by insufficient access, access that can sometimes take
days or even weeks to be granted.
For engineering platform teams, that is an especially acute problem. As it is part of their mission,
to provide a seamless experience and at the same time they need care for authorization of multiple offerings
that multiples the pain of any friction.
In large organizations, authorization can be a very complex topic.
Almost always it is tightly constraint with strict compliance requirements, while at the same time
it is intricately tied to the user experience. Who hasn’t had the experience of trying to access a resource they need
for work only to be stumped by insufficient access, access that can sometimes take
days or even weeks to be granted.
For engineering platform teams, that is an especially acute problem. As it is part of their mission,
to provide a seamless experience and at the same time they need care for authorization of multiple offerings
that multiples the pain of any friction.
Let’s analyze two different communication patterns:
Polling: Service B periodically query Service A for the current state of the users and updates its local storage.
Event driven: Service A publishes in a queue every time user information is updated. Service B consumes the updates to stay up to date.
Using TLA+ we are going to model the two different patterns to see how well they fit our requirements.
In our specification, we are also going to take into account unexpected failures that can affect the system and show how to model them in TLA+.
In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system.
AWS defines serverless as:
A serverless architecture is a way to build and run applications and services without having to manage infrastructure.
You design your system as a collection of small runtime entities, often connected to queues to exchange messages.
AWS offers services like Lambda and SQS to easily provision such systems.
With managed services, less development effort is required to have something up and running.
Additionally, they make it easier to build scalable and resilient solutions.
Let’s analyze two different communication patterns:
Polling: Service B periodically query Service A for the current state of the users and updates its local storage.
Event driven: Service A publishes in a queue every time user information is updated. Service B consumes the updates to stay up to date.
Using TLA+ we are going to model the two different patterns to see how well they fit our requirements.
In our specification, we are also going to take into account unexpected failures that can affect the system and show how to model them in TLA+.
In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system.
AWS defines serverless as:
A serverless architecture is a way to build and run applications and services without having to manage infrastructure.
You design your system as a collection of small runtime entities, often connected to queues to exchange messages.
AWS offers services like Lambda and SQS to easily provision such systems.
With managed services, less development effort is required to have something up and running.
Additionally, they make it easier to build scalable and resilient solutions.
Last week, I’ve re-read “Test Driven Development: By Example” by Kent Beck.
I was amazed by the simplicity of his process, consisting of small pragmatic steps.
So, I decided to put the process to the test in an unfamiliar domain.
The kata
In this kata, I am going to develop a serverless service in AWS using a Lambda and the API Gateway.
I chose this task because, on the one hand, it will contain a fair amount of infrastructure code, which is considered hard to test.
On the other hand, because I wanted a task that was more abstract and closer to a business requirement in contrast to a technical requirement like ‘deploy an AWS HTTP API Gateway’.
CloudFormation and Terraform are both tools to describe your infrastructure as code.
They enable us to easily provision, re-provision and update our infrastructure without losing control of all the changes.
I’ve used both tools many times in different products, and I was never in a situation that either tools let me down.
That being said both tools have strengths and weaknesses.
On the one hand, Terraform configuration files tend to be more concise and readable, on the other hand CloudFormation offers better support for rotating servers.
In this blog post, I am going to show you how you can use CloudFormation or Terraform for this job and what are the trade-offs of each tool.
In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system.
AWS defines serverless as:
A serverless architecture is a way to build and run applications and services without having to manage infrastructure.
You design your system as a collection of small runtime entities, often connected to queues to exchange messages.
AWS offers services like Lambda and SQS to easily provision such systems.
With managed services, less development effort is required to have something up and running.
Additionally, they make it easier to build scalable and resilient solutions.
In this guide, I want to demonstrate how to use TLA+ to specify a simple serverless system.
AWS defines serverless as:
A serverless architecture is a way to build and run applications and services without having to manage infrastructure.
You design your system as a collection of small runtime entities, often connected to queues to exchange messages.
AWS offers services like Lambda and SQS to easily provision such systems.
With managed services, less development effort is required to have something up and running.
Additionally, they make it easier to build scalable and resilient solutions.
Last week, I’ve re-read “Test Driven Development: By Example” by Kent Beck.
I was amazed by the simplicity of his process, consisting of small pragmatic steps.
So, I decided to put the process to the test in an unfamiliar domain.
The kata
In this kata, I am going to develop a serverless service in AWS using a Lambda and the API Gateway.
I chose this task because, on the one hand, it will contain a fair amount of infrastructure code, which is considered hard to test.
On the other hand, because I wanted a task that was more abstract and closer to a business requirement in contrast to a technical requirement like ‘deploy an AWS HTTP API Gateway’.
Last week, I’ve re-read “Test Driven Development: By Example” by Kent Beck.
I was amazed by the simplicity of his process, consisting of small pragmatic steps.
So, I decided to put the process to the test in an unfamiliar domain.
The kata
In this kata, I am going to develop a serverless service in AWS using a Lambda and the API Gateway.
I chose this task because, on the one hand, it will contain a fair amount of infrastructure code, which is considered hard to test.
On the other hand, because I wanted a task that was more abstract and closer to a business requirement in contrast to a technical requirement like ‘deploy an AWS HTTP API Gateway’.
This is a blog post about the trade-offs I’ve observed during agile software delivery with test driven development (TDD).
Agile and TDD are amazing, and I use them daily.
My hope is that by raising awareness about the trade-offs of our decisions, while applying Agile and TDD, will help us make better decisions.
Agile software development
Agile software development is a balance of two priorities.
On the one hand, we need to develop an application that satisfies the current requirements completely, correctly and economically.
When developing a new feature, I found that the use of the Null Object pattern can help keep the code releasable and naturally leads to the creation of a feature toggle.
Introduction
Every time I need to add some new functionality in my application, I face the same challenges, I need to make sure that my every commit does not introduce any regressions and also that I commit often so that my teammates and I always work on the latest code.
It is usually after a disaster (small or big) that people start proclaiming:
The application should NOT crash!
The application should NOT block waiting for that downstream service!
The application should NOT allow unauthorised access!
And similar statements describing what the application should NOT do instead of what it should.
After such a proclamation and since the statement, or at least the intention behind the statement is reasonable, people are left trying to figure out how to do that.
In my previous posts Sprint velocity, what is it good for? and Better sprint planning with Bayes, I talked about using statistics for more reliable forecasting and for quantifying uncertainty.
In this post, I want to show you the code to automate the process, so that us humans can focus on making decisions based on the data.
I am going to use Python for this example, because it has great libraries for data science and statistics.
I am going to use numpy and scipy.
Imagine you are working in a software development team doing Scrum with 2-week sprints.
If you are part of a larger organisation, it is likely there are delivery goals that go beyond the next sprint, let’s call them milestones.
Inevitably, someone from above is going to ask you:
“Are you on track? Are you going to make the next milestone?”
This is what happened to me recently, and I struggled to come up with an answer.
Looking around, I realised that many people are answering this question mainly based on their part experiences and on their personality.
Which means that if you are the one asking you need to take into account who in answering to properly interpret the answer.
Software development teams doing scrum try in one way, or the other to measure their velocity.
Velocity is usually measured as the number of completed stories or as the number of completed story points in a sprint.
The first one is pretty straight forward, the second one is a bit more elusive, so I am going to explain it further in the next section.
Especially, since I’ve seen teams spend quite some effort trying to get the story points right!
It is usually after a disaster (small or big) that people start proclaiming:
The application should NOT crash!
The application should NOT block waiting for that downstream service!
The application should NOT allow unauthorised access!
And similar statements describing what the application should NOT do instead of what it should.
After such a proclamation and since the statement, or at least the intention behind the statement is reasonable, people are left trying to figure out how to do that.
In my previous posts Sprint velocity, what is it good for? and Better sprint planning with Bayes, I talked about using statistics for more reliable forecasting and for quantifying uncertainty.
In this post, I want to show you the code to automate the process, so that us humans can focus on making decisions based on the data.
I am going to use Python for this example, because it has great libraries for data science and statistics.
I am going to use numpy and scipy.
Imagine you are working in a software development team doing Scrum with 2-week sprints.
If you are part of a larger organisation, it is likely there are delivery goals that go beyond the next sprint, let’s call them milestones.
Inevitably, someone from above is going to ask you:
“Are you on track? Are you going to make the next milestone?”
This is what happened to me recently, and I struggled to come up with an answer.
Looking around, I realised that many people are answering this question mainly based on their part experiences and on their personality.
Which means that if you are the one asking you need to take into account who in answering to properly interpret the answer.
Software development teams doing scrum try in one way, or the other to measure their velocity.
Velocity is usually measured as the number of completed stories or as the number of completed story points in a sprint.
The first one is pretty straight forward, the second one is a bit more elusive, so I am going to explain it further in the next section.
Especially, since I’ve seen teams spend quite some effort trying to get the story points right!
