There’s definitely a pattern here that I think gets promulgated by hyperscalers and major vendors. Even if not intentionally, but as a byproduct of engineering blogs and marketing meets well intentioned developers.
A good friend of mine is a solid developer generally, but he only works in AWS and while he leads a technical team, he doesn’t seem to have any idea what things actually cost in AWS.
He also seems somewhat susceptible to the hype trains that get started by AWS and customers of a much larger scale than his employer. He builds in the name of scalability but in ways that don’t necessarily address future organizational needs. I’ve seen this impact his work in ways that it isn’t my place to directly address, but that I know will come back to haunt his employer.
By way of example, he has built the service his current employer provides around the idea that each customer gets a different tenant that isn’t connected to any other tenant, and there is no ability even from their control plane to transfer data between tenants. His thinking was based on the idea from a prior employer where enterprise customers got their services managed in a customer specific AWS account managed by the company: total isolation. That made a lot of sense at his last two employers, but for the industry in which his current employer operates it is an anti-pattern. To draw an analogy, it would be like building an EMR that doesn’t have the ability to output patient records in a manner that another EMR could ingest. In his industry this sort of portability of end user data for his employer’s customers is both customary and expected.
This means his company has to build some kind of abstracting service that can enumerate and communicate across all customer tenants to shuffle data around or export it. It isn’t a capability anticipated in the architecture, but it’s a basic need.
Down-thread there is a reference to Conway’s Law. You can argue this kind of thing is a manifestation of that concept. My friend has never worked in this specific industry before, and so he just doesn’t understand their needs. He talks about it in purely AWS Well Architected terms and designs based solely on that for everything. That may be his job to an extent, but I think the broader problem is that no one in his company clearly communicated to him predictable end user expectations that impact architectural design.
> To draw an analogy, it would be like building an EMR that doesn’t have the ability to output patient records in a manner that another EMR could ingest. In his industry this sort of portability of end user data for his employer’s customers is both customary and expected.
That's not necessarily contradicting the design to me. I don't know AWS but I assume you still can move data between tenants, only through some export/import system. And there may be a good a reason for it. Like you need an import/export system anyway because your tenants need it for data exchange with "tenants" that are not your customers. So you can still have both. Another reason may be a need for auditing the data movements between those tenants.
A good friend of mine is a solid developer generally, but he only works in AWS and while he leads a technical team, he doesn’t seem to have any idea what things actually cost in AWS.
He also seems somewhat susceptible to the hype trains that get started by AWS and customers of a much larger scale than his employer. He builds in the name of scalability but in ways that don’t necessarily address future organizational needs. I’ve seen this impact his work in ways that it isn’t my place to directly address, but that I know will come back to haunt his employer.
By way of example, he has built the service his current employer provides around the idea that each customer gets a different tenant that isn’t connected to any other tenant, and there is no ability even from their control plane to transfer data between tenants. His thinking was based on the idea from a prior employer where enterprise customers got their services managed in a customer specific AWS account managed by the company: total isolation. That made a lot of sense at his last two employers, but for the industry in which his current employer operates it is an anti-pattern. To draw an analogy, it would be like building an EMR that doesn’t have the ability to output patient records in a manner that another EMR could ingest. In his industry this sort of portability of end user data for his employer’s customers is both customary and expected.
This means his company has to build some kind of abstracting service that can enumerate and communicate across all customer tenants to shuffle data around or export it. It isn’t a capability anticipated in the architecture, but it’s a basic need.
Down-thread there is a reference to Conway’s Law. You can argue this kind of thing is a manifestation of that concept. My friend has never worked in this specific industry before, and so he just doesn’t understand their needs. He talks about it in purely AWS Well Architected terms and designs based solely on that for everything. That may be his job to an extent, but I think the broader problem is that no one in his company clearly communicated to him predictable end user expectations that impact architectural design.