Hi everybody!
Welcome to the first issue of Interesting Bits, in which I filter through the Software Engineering related content to bring you news, tips, articles and papers worth reading.
In this issue:
- reducing Docker image size, scratch images and statically compiled binaries
- how to measure system availability
- first impressions on AWS XRay and gotchas for Golang users
- understanding the business value is the key aspect in a software architecture
Reducing Docker images size
Source: Jérôme Petazzoni
Among all the articles on the subject, this is the best I have read.
Great tips on how to reduce Docker images size, and it also features insights on statically vs dynamically linked binaries.
A statically compiled binary can run even in a Scratch image, because the binary will include all the libraries it needs, even libc. In golang to get a statically compiled binary use the GCO flag:
CGO_ENABLED=0 go build
Measure availability for systems
Source: Google Research Paper
A paper from Google engineers about measuring availability.
It's well written and very light on math; it's easy to picture how to implement the suggested approach to measure availability for our systems.
Some takeaways:
- Prefer time based (availability = uptime / (uptime + downtime)) metrics to count based metrics (availability = successful requests / total requests)
- After a successful (or failing) operation, assume that the system is up (or down) until the user sees evidence to the contrary.
- If no request arrives within a cutoff duration the segment is marked as inactive and does not count towards user downtime or uptime.
- use different time windows, i.e. 1 minute, 5 minutes, 1 hour and graph them at different percentiles
AWS XRay first impressions and gotchas
Source: myself
Takeaway 1
XRay allows to build a latency map for a request.
The number in the circle is the time between the moment the request entered the node and the one in which it exited.
By clicking on the edge, you get the time for the request to reach the next node. Notice that this measure is only accurate if the next node is instrumented with XRay, otherwise it's an estimate computed on the caller side.
Takeaway 2
Dropping in XRay in an existing application is easy, just wrap the client.
Instrumenting http calls made via an http client:
client := xray.Client(&http.Client{})
req, _ := http.NewRequest(http.MethodGet, "...", nil)
res, _ := client.Do(req.WithContext(r.Context()))
Instrumenting calls to AWS Services:
// DynamoDB example
dynamoDbSvc := dynamodb.New(sess)
xray.AWS(dynamoDbSvc.Client)
Takeaway 3
Using XRay in a Lambda with Golang requires a XRay libray version greater or equal to v1. This is important, otherwise you will be presented with a cryptic error message at runtime!
go get –u github.com/aws/aws-xray-sdk-go@v1.0.0-rc.14
Takeaway 4
You need to pass the context to each call you make. In the following snippet, notice the PutItemWithContext call instead of PutItem:
func handleRequest(
ctx context.Context, request events.ALBTargetGroupRequest)
(events.ALBTargetGroupResponse, error) {
...
_, e = dynamoDbSvc.PutItemWithContext(ctx, &dynamodb.PutItemInput{
Item: av,
TableName: aws.String(tableName),
ConditionExpression: aws.String("attribute_not_exists(wid)"),
})
If you are running in a Lambda, the context is what you receive from the Lambda invocation. Otherwise you need to create a new Context.
If you get an error like:
failed to begin subsegment
named 'dynamo': segment cannot be found.
Then you likely forgot to pass a context to the request.
Takeaway 5
Many services integrate with XRay, for example API Gateway.
If you enable XRay for API Gateway via console or CloudFormation you need to manually trigger a deployment. Otherwise you'll get UNAUTHORIZED from API Gateway!
Business value is the most important aspect when designing architectures
Source: Martin Fowler's blog
Software architects tend to describe the performance of these systems, how resilient they are to faults, and how they are designed to evolve to easily support new capabilities. The elephant that rarely comes up, however, is how different systems contribute to business value.
Business value is the most important aspect to consider when designing a system architecture. Both functional and non functional requirements depend on business.
Takeaway 1
Consider the business value impact of failures. If we want to take measures to improve the resilience of a system, it's good to express it in terms of the value at risk should it fail. An important part of analyzing how much value is at risk is recognizing that, since different failures have differently severe consequences, all software components do not need the same levels of resilience
Takeaway 2
What's the cost for the business of less resiliency, scalability or speed?
Modulate the effort to achieve these system attributes based on the actual value provided to the business.
Takeaway 3
Consider the cost of configurability or other premature optimizations
Takeaway 4
When doing an assessment of value that would be at risk, it's worth approaching in two complimentary ways. One route is to go top-down, looking at a business function and identifying which software systems support that function. The other is the reverse, starting with a software system, and considering what ramifications a failure here would have.
Top-down
I.e. Which features make money? What are the components of the system which implement the feature? This would be the most valuable pieces of the architecture.
Bottom-up
If this component would go down, which features would be impacted? What would be the lost value?
Conclusions
...and this is all for this issue.
Some of the content I write is too short for a post, but still interesting enough to share it as a tweet. Follow me on Twitter to get them in your Twitter feed!
Credit for the cover image to GraphicMama-team
Top comments (0)