This adds two hypothetical variants to the Mu demo, "building" new capabilities
up from the basic Express and MongoDB app we start with:
1) The first variant is to leverage the Mu SDK for service discovery and
configuration, eliminating the "loosely typed" approach that is common with
Docker (e.g., having to fetch connection URLs from arguments, environment
variables, etc). This extends the Mu type system "into" the Docker container,
whereas previously it stopped at the boundary.
2) The second variant really takes this to the next level, embellishing the nice
DSL-like approach. In this model, infrastructure is expressed in code.
Instead of manually creating a volume, we will arrange for the mongodb/mongodb
to auto-mount a mu/x/fs/volume, as per [the cloud-neutral design doc](/docs/xcloud.md).
This just adds a simple voting app for the demo script. It leverages
a Node.js Express app for the frontend and a MongoDB database for the backend.
It conditionally provisions and attaches to an AWS Elastic Block Store volume
in the event that it's targeting an AWS cluster, and ephemeral storage otherwise.
This change separates the metadata specification from the targets doc,
since they are both meant to be consumable independent of one another
and will evolve at their own paces.
This sketches out some more details in the Metadata format, in addition to
starting to articulate what the AWS IaaS provider looks like. Sadly, more
questions than answers, but it's good to have the placeholders...
Simple developer scenarios can be done solely in terms of Stacks. However, to
support more sophisticated cases -- where multiplexing many Stacks onto a shared
set of resources is preferred (for cost savings, provisioning time savings,
control, etc) -- we need to introduce the concept of a Cluster. Each Cluster has
a fixed combination of IaaS/CaaS provider, decided at provisioning time.
This just contains primarily scaffolding, however lays out a general direction
and table of contents for the metadata specification document (marapongo/mu#1).
This doc will describe the overall architecture for the Mu tools, platform,
and related artifacts. It will be a companion to the more detailed drill-down
into the Mufile format and its specific target transformations (marapongo/mu#1).
There are tons of todos, etc., however this is at least a start, with some
amount of conceptual overview plus scaffolding and structure to fill out.
This was really just a brainstorming exercise that helped get to the final
model we landed on. I'm archiving it for posterity. I'll decide whether to
carry it forward or delete it and leave it as an artifact for future reference
as I make more progress on the overall architecture and file format specification.
This snapshots thinking as of maybe two weeks ago. I'm preparing to
do a big overhaul of all of the write-ups, and specifically start on the
Mu.yaml file format spec, and so I want to archive everything that's in flight.
This was an interesting example I found in the Mulesoft GitHub repos. It seemed like
a perfect candidate for Riff/Mu/Lambda, so I sketched out what it might look like.
This change adds a .mu/ directory to the vote50 app. Inside are the "expected"
contents that the Mu compiler should output. Eventually we will validate against
this that the (currently non-existent) compiler generates the correct thing.
This isn't complete, although I can manually create bits and pieces of the stacks
using CloudFormation. More files will come; for example, the code packages.
In a nutshell:
.mu/ # Shared files agnostic to the cloud target
aws-native-cf/ # Files specific to the AWS CloudFormation target
app.template.yaml # The CloudFormation stack for the overall app
services/ # A directory containing service-specific stacks
voting.template.yaml # The CloudFormation stack for the VotingService
services/ # Service files agnostic to the cloud target
voting.proto # The gRPC definition for VotingService's API
mu.yaml # The Mu package manifest (minimal for now)
Instead of leading in with the Service-based voting application, and then
simplifying it to a serverless Function-based one, do it in the reverse order.
This allows us to "grow" the sample, motivating each change as we go.
