Added architecture-patterns.md #332
Conversation
|
There was a problem hiding this comment.
There are a few places in here where what we actually want to do is to get a conversation kicked off if someone finds themself on the wrong side of a SHOULD. I'm not sure it's right that we present this document as a formal checklist in itself; if someone finds themself in the position where they genuinely need new services on VMs, then it's important we know about it.
| This is the default technology for building services using Cloud Hosting Services. The rationale for this is that it: | ||
|
|
||
| * Reduces the overhead of infrastructure management to an absolute minimum. | ||
| * Prevents the development of Monolithic applications. |
There was a problem hiding this comment.
This is an optimistic take. It doesn't stop you from building a distributed monolith, and if you already can't modularise well, it makes fixing boundary problems harder.
| * [AWS Lambdas](https://docs.aws.amazon.com/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/sample-architecture-patterns.html) | ||
|
|
||
|
|
||
| The following criteria permit __Rule 1__ to be broken |
There was a problem hiding this comment.
If we've got criteria for breaking it, that makes it a SHOULD, not a MUST, as above.
There was a problem hiding this comment.
I'm not convinced that "SHOULD xxx unless yyy" makes the SHOULD clause strong enough.
There was a problem hiding this comment.
Nevertheless, that's the logic here. "Do this, no exceptions" is a MUST. "Do this... unless..." is a SHOULD. I don't think we call out RFC 2119 anywhere here, but that would be the interpretation I would expect readers to have.
|
|
||
| ## Compute Selection | ||
|
|
||
| ### Rule 1 Your Service MUST be built using __Function as a Service__ technologies |
There was a problem hiding this comment.
| ### Rule 1 Your Service MUST be built using __Function as a Service__ technologies | |
| ### Rule 1 Your Service SHOULD be built using __Function as a Service__ technologies |
See below
| Our preferred managed services are: | ||
|
|
||
| * [AWS ECS](https://aws.amazon.com/ecs/) | ||
| * Only where ECS can NOT be used, [EKS](https://aws.amazon.com/eks/) should be considered, this is because of the shift of management responsibility from Customer to Cloud Hosting provider that ECS offers over EKS. |
There was a problem hiding this comment.
We probably want to move EKS to CONTAIN for this, and just point to the radar and the Engineering Board to ratify a choice to use it (or update the ring)
There was a problem hiding this comment.
I need to fold in how these relate to the Tech Radar then?
There was a problem hiding this comment.
There's a bit of a question mark here. We've said (internally, no reason for you to have knowledge) that we don't want links to internal sharepoint docs on our externally-published docs. Pointing to the tech radar would imply pointing to the internal docs which detail the tech radar process. I suspect that the right thing to do is to remove this "preferred services" section entirely.
| * [AWS ECS](https://aws.amazon.com/ecs/) | ||
| * Only where ECS can NOT be used, [EKS](https://aws.amazon.com/eks/) should be considered, this is because of the shift of management responsibility from Customer to Cloud Hosting provider that ECS offers over EKS. | ||
| * [Azure Container Apps](https://techcommunity.microsoft.com/t5/apps-on-azure-blog/build-intelligent-apps-and-microservices-with-azure-container/ba-p/3982588) | ||
| * Only where Azure Container Apps can NOT be used, [Azure AKS](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks-microservices/aks-microservices) should be considered, this is because of the shift of management responsibility from Customer to Cloud Hosting provider that Azure Container Apps offers over Azure AKS. |
There was a problem hiding this comment.
Again, this should be a move of AKS to CONTAIN, really.
| * Has the ability to automatically scale to Zero, with fast start-up / scale-up times. | ||
| * Encourages a reduction in the size of deployable components. | ||
|
|
||
| Functions SHOULD be delivered as individual capabilities, rather than one function routing traffic internally to different capabilities (see for example this AWS anti-pattern). |
There was a problem hiding this comment.
Missing a link? Also I disagree that this is clear-cut enough to assert as a SHOULD. What's the reasoning for us here?
There was a problem hiding this comment.
See: https://docs.aws.amazon.com/lambda/latest/operatorguide/anti-patterns.html lists several drawbacks of Lambda Monoliths. It also indicates a misunderstanding of what FaaS 'is', i.e. it's just another runtime thatI can run my code on.
There was a problem hiding this comment.
I'd say that there are major holes in that document. All the listed factors other than the granularity of the security boundary make strong assumptions about traffic patterns and deployment workflows which just aren't going to be universally true or relevant. For instance, yes, you do need to have a way to avoid having developers tread on each others' feet for maintenance to be tractable. Is forcing a function-based architecture on the system the right way to do that? Does a function-based architecture even give you that, necessarily? No, not in my experience, unless you couple it to other changes as a consequence, which we may not want to buy into.
That's just one obvious gap. You can make similar arguments about package size, upgrades, code reuse, and especially about testing.
I think if we're going to have a strong position on this one, we need to understand why it's correct for us to be doing it, with reasoning that applies to the specifics of how we develop code, rather than appealing to the authority which we pay per function call.
Co-authored-by: Alex Young <[email protected]>
Co-authored-by: Alex Young <[email protected]>
Co-authored-by: Alex Young <[email protected]>
Co-authored-by: Alex Young <[email protected]>
Added architecture-patterns to reinforce the pattern of outsource bottom up.