DEV Community: Pete

Adding additional services into Amplify

Pete — Wed, 07 Jul 2021 16:48:39 +0000

Michael Liendo's post Serverless Contact Form Using AWS Amplify reminded me of something I learnt about adding additional "not natively supported" services into Amplify.

When I say "not natively supported", I mean you can't create the resources with the cli. Rather than, Amplify doesn't support them at all. Of course your application will, you've access to the AWS SDK after all...

Sending a simple templated email...

Like Michael's example, I wanted to simply create an email to invite people to an organisation in the slate. The difference was I wanted to use an SES email template, so that I could have different environmental versions.

SES templates?

Rather than have the actual email template like so

await ses
  .sendEmail({
    Destination: {
      ToAddresses: [process.env.SES_EMAIL],
    },
    Source: process.env.SES_EMAIL,
    Message: {
      Subject: { Data: 'Candidate Submission' },
      Body: {
        Text: { Data: `My name is ${candidateName}. You can reach me at ${candidateEmail}` },
      },
    },
  })
  .promise()

You can do something like this,

var emailTemplate = {
  Destination: {
    ToAddresses: []
  },
  Source: `The Slate <${inviteEmail}>`,
  Template: 'SLATE_INVITE',
  TemplateData: `{ \"invited_by\":\"${userDetails.name}\", \"invite_url\": \"${url}\" }`, // THIS HAS TO BE A JSON ESCAPED STRING!?
  ReplyToAddresses: [
    `The Slate <${inviteEmail}>`
  ],
};

await ses.sendTemplatedEmail(emailTemplate).promise();

SLATE_INVITE is a reference to an HTML and Text email template held in SES, and it will accept the references and data in TemplateData to be rendered in the template. To me it's a nice / clearer way of making changes to the template.

Kicking it up a notch

For some reason, I've no idea why, I decided to put the HTML and text templates into /amplify/backend/email.

Then in my infinite wisdom I wondered, could I make a Cloudformation template for this?

My rational was that I could deploy environmental/versioned templates alongside everything else, and if I had to spin the slate up on a different AWS account, it wouldn't be a problem. The short answer is yes, yes you can.

As you can imagine, it didn't take long to go "If I have a cloudformation template, could add it to the existing Amplify cloudformation set-up?". Again, turns out you can do this too.

Extending your Amplify Cloudformations

You may have never have noticed, but there is a file at /amplify/backend/backend-config.json that describes your amplify resources, e.g.

"storage": {
  "slate": {
    "service": "DynamoDB",
    "providerPlugin": "awscloudformation"
  }
},

The format of the json describes two things;

"Storage" is both the "Category" you see in the cli and a folder (/amplify/backend/storage)
"slate" is "Resource name" you see in the cli and a folder (/amplify/backend/storage/slate) holding the cloudformation template

If you were to add something like

"email": {
  "invite": {
    "service": "SES",
    "providerPlugin": "awscloudformation"
  }
},

In theory it will be picked up.

In theory you say?
Yes - because you need to have /amplify/#current-cloud-backend/amplify-meta.json refreshed to see your new service in the cli.

Once that happens, when you will see your new custom service and it will execute as part of the cloudformation stack. If it isn't there, it won't.

What is your error budget?

Pete — Mon, 14 Jun 2021 16:48:18 +0000

Part of the reason I built The Slate was because I've seen this common pattern too many times.

Service A (that people interact with) relies on Service B and C. Service B & C constantly fail, but Service A gets a bad rap with their users. The teams responsible for B & C don't know about the impact they are having on Service A. The team running Service A doesn't know Service B or C's error budgets, which is much lower.

What's an error budget?

Pretty simply, an error budget is the maximum amount of time that a team is "happy" to allow a system or service to fail. Usually you'll see it represented as a percentage of availability (e.g. 99.99% uptime!).

If you were to break down the percentages per month, you'd get;

99.000% is 7h 18m 18s per month
99.900% is 43m 50s per month
99.990% is 4m 23s per month
99.999% is 26s per month

Some of these can be pretty tough targets to hit, that might not be required for your business. I'd say a marketing site could easily handle an error budget of 99.9%. An e-commerce site might need to be 99.99%.

Just remember, five 9s (99.999%) can be significantly more expensive than four 9s (99.99%) to achieve. Particularly if you don't have the budget, resources or business support to achieve them.

What about those upstream services?

The services you depend on might have a different error budget. Like in my example earlier, Service A had a budget of four 9s. They had the budget, processes and resources in place to achieve that. But the other services had error budgets of two 9s.

As the owner of Service A, you have a choice. You might be able to build Service A to be resilient of downtime for Service B and/or C. But if you can't, then you've got two options;

Reconsider your error budget to reflect your dependancy's budget
Speak to the other Service's teams about their error budgets, and if it is possible to improve it.

Who is happy with downtime?!

No one really is. But you have to be realistic, not every service is, or should be, five 9s. Outages happen. How we respond to them, learn from them and adapt to them is the vital part here.

The first step in dealing with them however is being transparent about what each service's error budgets are, and how they might have an impact on dependant service.

This one very small aspect of the governance of your microservices, but it can easily increase your reliability and resilience.

How a viral video helped me design my MVP

Pete — Wed, 09 Jun 2021 09:55:52 +0000

If you’ve ever worked as product manager or a technologist working within a complex technology ecosystem, you’ve likely had a conversation like this before.

Usually tho, it’s a little less humourless…

About a year ago, I came across that video. I chuckled along — it’s funny ‘cause it’s true — and promptly forgot about it.

One year later

As I was building the MVP for the Slate, I came across it again. It stuck me, this is the type of problem I’m trying to help solve.

Highlighting and communicating dependancies between microservices, architectural decisions and product requirements is hard. So I took the video and tried to work out two things.

Does the Slate have all the functionality there that they describe?
What would this technology estate even look like if they used the Slate?

The results

After some tweaking and a missed piece of functionality (“deprecation notices, how could I have forgotten those?!”), I had a result.

A service specification for Entropy Khaos Service (EKS) which is being deprecated
A service specification for Omega Star, the replacement for EKS
An architectural decision that everything should support ISO timestamps
And of course, Galatcus, the all-knowing user service provider aggregator.

Could the Slate have helped?

Would the Slate have stopped an awkward conversation between a Product Manager and Developer that ended in crying? I’m not sure.

Would the Product Manager have known about how the services interrelate, what the blocker for Birthday Boy is and why? I’d say so.

I know that it’s an exaggerated scenario, but it’s pretty close to the truth as well. It also gave me a nice “demo-able” example for people to see/interact with the service.

Overall, it felt like a worthwhile endeavour. Although I’m sure I’ve missed something, somewhere.

A Microservices Service Catalogue? (or why I built the Slate)

Pete — Fri, 04 Jun 2021 10:48:45 +0000

About six months ago, I saw a great talk by Nora Jones’ called “Rethinking chaos engineering” — I was inspired, not so much by the chaos engineering, but by something else.

You see, I’d seen these pattern in a bunch of different organisations;

Pattern 1:
Service A (that your audience interacts with) relies on Service B and C. Service B & C fails, but Service A gets a bad rap with their users. The teams responsible for Services B & C don’t know about the impact they are having on Service A.

Pattern 2:
New product owner comes into a team. The don’t understand the technology estate. They are left with questions like “Is Service A more important that Service B?” “How critical is Service C to my overall priorities?”.

So I spent a few nights pulling together a Proof-of-Concept called Spectacle.

My solution was to create a dashboard that would capture, displaying and communicate service’s SLIs, SLOs, SLAs, their dependancies and align the service closer to business priorities.

I saw the purpose of the concept as a way of facilitating a conversation between teams about the importance of a service within a microservice estate.

I got some lovely feedback from a few folks, made a few tweaks and moved on.

Four months later

I had started playing around my next PoC — content workflow/state management — when it stuck me something major was missing from Spectacle; Architectural decisions.

Helping to build a complete picture of each microservice within your estate is one thing. Building an understanding and consensus amongst teams on the direction, challenges and impacts those microservices are facing is the next logical step.

I’ve seen too many architects in organisations make decisions upon high and not communicate them at all (or particularly well). Then disaster hits, because the impact of the decision reaches the service teams and doesn’t fit.

So taking some cues from Riot Games on how they do Tech Design and Michael Nygard’s documenting architecture decisions I decided to add it into Spectacle. But it would need a major change.

Spectacle was ‘single user’ — it saved your data locally in your browser, using local storage. You couldn’t export or easily share your data, this required a major shift.

A macro/micro/nano-SaaS?

User authentication, multi-tenancy, databases, APIs. It was all starting to look like a fully fledged software-as-a-service. So I thought, why not launch it as one?

I decided to use an old domain that I had never used and see what happens. Two months later, The Slate went live.

I do believe in the power of insights and open communication. The more you and your teams know, the better decisions you make. I don’t expect the Slate to become the “next big thing”. But if it helps one or two teams have a better understanding of their organisational context, then I’ve done something useful.

What’s next?

Going back to the feedback from the Spectacle PoC, there were two major comments.

I can’t share it with anyone (Resolved!).
I’d like to see summaries from monitoring and alerting systems alongside a particular service.

So, depending on how well the launch goes I’m going to start looking at 3rd party integration and see where that leads me.