What's worse in 2021: a monolith, or a proprietary vendor lock-in?

1

Hi everyone,

Having had my first Hello World somewhere back in 2007, for the longest time I have been that old dog that never learns new tricks. One of my regrets now is not adopting any existing PHP frameworks back in late 00s, and instead trying to roll my own. I eventually gave up though, and little by little I have embraced CakePHP by mid 10s.

Still, even with CakePHP, over the last year or so, I have been realising I’m stuck in that 2007 LAMP/LNMP mindset, where you have one website that does everything, without realising that the world had apparently moved on to microservices. I mean of course we send out e-mails using AWS SES, but that’s not really a microservice.

One encounter that has triggered the thoughts resulting in this post is A tale of a dying monolith, where the whole point is getting away from CakePHP. The architecture he ends up with almost fully depends on proprietary technology from 3rd companies, from Prismic to Buddy.works.

Prismic brags about raising 20M to build some kind of slice-based website technology (it’s so many layers of abstraction by now, it seems to have its own learning curve). Good for them! But are they profitable, or will they burn through the money and shut down?

So here I am: on one hand, for the longest time I have been seeing the closed-source, proprietary tech be frown upon. On the other hand, for an MVP-driven development, I’m supposed to drag and drop my no-code AWS SQS module instead of setting up the (seemingly impressive) dereuromark/cakephp-queue plugin

I’m leaning towards owning your code and being able to install it on a bare Linux box. Maybe due to the same reasons why I didn’t “trust” a framework 10 years ago. But is it even reasonable now?

Are microservices the future or a buzz word? How does CakePHP fit into that future?

Please share what do you think or feel

2

Until now I only make “small monoliths” when starting somewhat big projects.

I choose to create a base app with shared models (users, files, permissions, “clients”, “suppliers”, “projects”, etc) and then a plugin for each “mini-monolith” with migrations on each.
All in different repositories as the front-end is another repository for each, but the first time it was all in one repository and worked fine.

As for vendor lock-in, that depends, but for now i tend to use abstractions, like using an s3 client (cakephp-upload, etc) to use with S3 or with a self-hosted minio

Use docker, once you build an image for the project, it works everywhere and you don’t have to deal on “works on my machine”. See this video of cakephp-fest 2017 (but don’t use rancher 1.x, use docker-compose o learn a docker orchestrator after)

3

Hi, thank you for sharing your opinion.

It’s funny about S3, it doesn’t feel proprietary to me anymore. I’ve been seeing a lot of non-Amazon companies offering S3-compatible storage, so it even weirdly feels like a kind of open technology, as in you can move your storage needs away from AWS supposedly at any time, and your code and system will keep working.

Although right now we are, in fact, using AWS S3.

Thank you for the minio reference, first time I’m hearing about it, I will look into it. Always excited to learn something new.

As for the Docker, thank you for the link to the Cake Fest video. Never had time to actually try it, so this will be my closest to getting my hands on it :smiley: