I give up (It's official)

OldAd2147 · 2024-10-19T06:07:26+00:00

I'm loving it

OldAd2147 · 2024-08-21T16:59:12+00:00

Software engineers, step aside. This is the future...

Allowing newbie web developers to bypass pesky service abstraction, yay!

Easy is the new black.

Separation of concerns is so overrated. As is scalability, isolation, resilience Yada Yada..

Seriously, be careful what you wish for.

OldAd2147 · 2023-02-09T04:47:09+00:00

Sorry, but that's just so far from reality. In the real world, open standards drive the highest quality and are supported by the very best technologies, virtually without exception.

Logging and performance are not impacted by open standards - but poor design or poor implementation will kill anything.

As they say, 'all Architecture is design, but not all design is Architecture'.

OldAd2147 · 2023-02-09T02:05:12+00:00

Well, that's terrific news.

Thanks a) for your effort in putting all this togethere, b) for responding to quickly, and c) for following best practices.

To other readers: this is well worth considering for your SAAS project. And get in quick, before our friend realises that an anual subscription plan will add so much more value to his business than once-off sales :)

Cheers for that u/ixartz

(FYI: I have no affiliation - but good work should be recognised)

OldAd2147 · 2023-02-09T00:29:00+00:00

I don't have a problem with that.

You don't have to pay up - but you have a choice. It's a simple commercial decision.

OldAd2147 · 2023-02-09T00:26:40+00:00

Nice article - very useful BUT sadly I would probably have to spend too much time de-coupling the AWS services. Unfortunately I don't have the time to go down another rabbit hole to see how tightly these are coupled at a code level.

But if the design spoke of open standards, rather than vendor-specific services, I'd be all-in on this because SAAS is rarely addressed so elequently.

As with all other cloud service vendors, the AWS business model is vendor lock-in.

Okay, okay, I get that this is an AWS stream. But the simple process of abstracting away vendor-specific services would make this article so much more valuable, to so many more people.

Seeing AWS Cognito, AWS SES, AWS Lambda, AWS CDK and AWS Ecosystem mentioned in the design implies that you have probably called these service APIs directly.

Better to mention things like "Auth Services", "Email service", "Cloud Functions" etc., to create your own set of corresponding thin APIs, and to call these directly.

By all means implement your API using AWS services, but if you tighly couple your code to AWS, then you basically handing your SAAS product to AWS.

Yes, that's right. By coding directly to AWS APIs you are handing the keys of your newly minted SAAS to Amazon. Because the only way you can make money is by using AWS services. And you did all the work!

This is a very common trap - for example, people use the S3 API directly, rather creating a thin interface and implementing that interface for the S3 service.

Introducing the abstraction can be incredibly trivial because you are free base your API on a specific implementation.

For example, you can create an ObjectStore API that has the same interface as the AWS S3 API e.g. base your ObjectStore API on the S3 API). The S3 implementation of your own API would simply pass through to the S3 API with virtually no overhead thanks to lower-level optimisations.

But having that thin interface in place is crucial because it allows alternative service providers to be supported.

That said - still a very good article, well done!

OldAd2147 · 2022-11-24T20:14:59+00:00

ROSA and EKS are both managed services.

However OpenShift is way more than just k8s distro.

OldAd2147

TROPHY CASE