While I love what the Juju community is doing, the vehicle of what’s being built is still very Bare metal / VM / Infrastructure centric.
I think it’s amazeballs that the building of those vehicles is completely abstracted, but I’m interested to see what the Juju community members are doing / thinking with regards to making applications consumable on Serverless and SaaS vehicles?
Why don’t you expand a bit more on your line of thinking? I’m not following exactly here but I have a feeling you’re on to something here.
Yeah I was mulling over something similar this morning.
K8S support is a cool feature to have, but there’s a few more pieces to the puzzle that could make the whole platform interoperability stuff amazing.
Serverless is one, utilising a charm to deploy a serverless workload to the platform of choice. But also more generic stuff that I want to be able to prototype, like charms that allow you to connect various disparate SaaS platforms together.
For example an interal website I’m currently working on, has a website in an S3 bucket, which talks to the AWS API Gateway, which in turn talks to a Lambda function which queries a Dyanmo DB table. It also uses AWS transcoder for video transcoding which in turn uses another Lambda function and another API gateway call and S3 for video storage.
Now I don’t think my example is particularly complex or uncommon, but it does require security group management, lambda function deployment and so on, all of which requires knowledge. I could tell you a few stories about AWS security groups at JPL… but I won’t! 
On top of this we make loads of use of AWS Elastic Search, AWS K8S, AWS Cloudfront etc… but have also just started using Google Cloud… which is a whole other pain point and services that need to interoperate between the two.
So one example is a two tiered app on Azure.
A front end and a backend database.
Juju would spin up two VMs install say nginx on the frontend and postgres on the backend.
I’m thinking instead of spinning up vms at all why not request cloud services like Azure Postgres or a Container or a Azure function and then inject whatever it is you’re trying to do into that service, as apposed to a VM.
This is an interesting discussion. My initial thoughts on this is asking if this is a fit for Juju as a whole. I normally think of Juju as an operations tool and while folks focus on the “deploy” or “install” step the real value and interesting fun bits are in the longer term operations side of things.
In these scenarios is the value folks are looking for is abstracting the way the different clouds provide the same resource (load balancing, pgsql db access, etc)? Or is it providing that sane overview of what is being provided by the different chunks of functions floating around? e.g. providing some sort of identity and description on the functions registered doing those queries or something along those lines?
I think you raise a few good points Rick.
Some stuff makes sense to loop into, for example, it would be cool to be able to deploy a charm that deploys a Lambda function or something automatically along with your other apps and have a relation know what its doing with the output (assuming it was outputted somewhere readable).
There’s other stuff that some proxy charms make sense with, I keep beating the LDAP dead horse, but for example databases, sticking stuff into one of the AWS databases may make more sense than running a MariaDB instance on AWS, so having a charm that can provide the abilty for other charms to at least relate to it would be very useful (I know clearly I could write this, I’m just posturising here). Same with cross cloud stuff from hosted services, database on one, VM running some workload on another.
I don’t think you’re looking for a service registry or overview Juju is overkill for that.
@rick_h so one of the reasons I got thinking about this was exactly the day 2 stuff… ‘dealing with it after it exists.’
There’s a number of deployable applications available in the Charmed store, some of them I’d love to use but they seem to be stuck in the past - like Zabbix, I’d love to deploy Zabbix but it’s built on Trusty and I really don’t want to have a Trusty instance amongst my Bionic and Disco landscape. Its almost as if it got left behind because newer toys came along.
When using a SaaS / PaaS / Cloud native services that problem really does go away completely, there are other things to consider but for the most part- “it’s not my problem anymore”.
The “next gen” charm could just be a relatable construct to some underlying cloud native service.
This sounds like a rant, but it really isn’t, I’m just excited about the things that are out there at the moment.
One of the things that I’m hoping we’ll get better at as a community is making it easier to pick up ownership of old charms and bring them forward.
It’s actually pretty easy to download an old charm, add some tweaks (say, support for a new series …) and then deploy it as a local charm. But that’s poorly documented and it’s also a lot of work if you’re used to just issuing juju deploy zabbix. There’s even more work to do if you want to be able to push your changes up for others.
We (Canonical) are hoping to launch a significantly better charming experience fairly shortly. Hopefully that will spur a lot of momentum.
I will ask this, and I don’t have an answer, but I was looking around PuppetForge trying to figure it out last night and failed.
Do you think the Charm Store layout as it currently stands helps foster communities over disparate charms?
I don’t, and its something we need to improve.
