26 ms·
It says "BaaS" in one diagram, I didn't know that one. I've probably been referring to the same as "Middleware-as-a-Service". And I'm disappointed in it. As ama
by sverhagen 9y ago
It says "BaaS" in one diagram, I didn't know that one. I've probably been referring to the same as "Middleware-as-a-Service". And I'm disappointed in it. As amazing as it still is that Amazon and friends let you spin up machines at will, this day and age, I find us (where I work) still rolling a lot of stuff ourselves, that I'd hope by now to be able to buy as a service inside Amazon. (From Amazon, or from 3rd parties that integrate into your Amazon account, somehow magically, I don't know what that model would be.) Still we're doing our own Elasticsearch, JMS, databases (been burned on RDS), cache, Kubernetes, and so on. Is this just a market that hasn't matured yet? (While SaaS probably has?) Not because AWS offers nothing for it, but just because it's quite not always the best of breed.
(Disclaimer: while we practice DevOps quite a bit, me being a Java architect, I'm still not an operations expert, so I may well overlook something real obvious...)
- athenot 9y agoWe use it for cases where we don't need that much customization. Everything you do yourself has a maintenance cost (setup, patching, security, monitoring, fixing state, backups...). If that component is integral to your service, roll your own and manage it with your standard config management. If it's a component for an auxilliary tool (say you need a backend to store some dashboard thingy), it's better to use these middleware services.