With serverless, you stopped caring about the server.
With Sigma, you stopped (or will stop, if not already) about the platform.
Now all you care about is your code - the bliss of every programmer.
Or is it?
I hold her (the code) in my arms.
If you have done time with serverless frameworks, you would already know how they take away your platform-phobia, abstracting out the platform-specific bits of your serverless app.
And if you have already tried out Sigma, you would have noticed how it takes things further, relieving you of the burden of the configuration and deployment aspects as well.
Leaving behind just the code.
Just the beautiful, raw code.
So, what's the catch?
Okay. Now for the untold, unspoken, not-so-popular part.
You see, my friend, every good thing comes at a price.
Lucky for you, with Sigma, the price is very affordable.
Just a matter of sticking to a few ground rules while you develop your app. That's all.
Resources, resources.
All of Sigma's voodoo depends on one key thing: resources.
The concept is quite simple: every piece of your serverless app - may it be a DynamoDB table, S3 bucket or SNS topic - is a resource from Sigma's point of view.
If you remember the Sigma UI, the Resources pane on the left contains different resource types that you can have in your serverless app. (True, it's pretty short; but we're working on it :))
Behind the scenes
When you drag a resource from this pane, into your code, Sigma secretly creates a resource (which it would later deploy into your serverless provider) to track the configurations of the actual service entity (say, the S3 bucket that should exist in AWS by the time your function is running) and all its usages within your code. The tracking is fully automated; frankly, you didn't even want to know about that.
"New" or "existing"?
On almost all of Sigma's resource configuration pop-ups, you may have noticed two options: "new" vs "existing". "New" resources are the ones that would be (or have already been) created as a result of your project, whereas "existing" ones are those which have been created outside of your project.
Now that's a tad bit strange because we would usually use "existing" to denote things that "exist", regardless of their origin - even if they came from Mars.
Better brace yourself, because this also gives rise to a weirder notion: once you have deployed your project, the created resources (which now "exist" in your account) are still treated by Sigma as "new" resources!
And, as if that wasn't enough, this makes the resources lists in Sigma behave in totally unexpected ways; after you define a "new" resource, whenever you want to reuse that resource somewhere else, you would have to look for it under the "existing" tab of the resource pop-up; but it will be marked with a " (new)" prefix because, although it is already defined, it remains "new" from Sigma's point of view.
Now, how sick is that?!
Perhaps we should have called them "Sigma" resources; or perhaps even better, "project" resources; while we scratch our heads, feel free to chip in and help us with a better name!
Rule o' thumb
Until this awkwardness is settled, the easiest way to get through this mess is to stick to this rule of thumb:
If you added a resource to your current Sigma project, Sigma would treat it as a "new" resource till the end of eternity.
Bottom line: no worries!
Being able to use existing resources is sometimes cool, but it means that your project would be much less portable. Sigma will always assume that the resources referenced by your project are already in existence, regardless of whatever AWS account you attempt to deploy it. At least until (if) we (ever) come up with a different resource management mechanism.
If you want portability, always stick to new resources. That way, even if a complete stranger gets hold of your project and deploys it in his own, alien, unheard-of AWS account, the project would still work.
If you are integrating with an already existing set of resources (e.g. the set of S3 bucket in your already-running dev/test/prod environment), using existing resources is the obvious (and the most convenient) choice.
Anyways, back to our discussion:
Where were we?
Ah, yes. Resources.
The secret life of resources
In a serverless app, you basically use resources for two things:
- for triggering the app (as an event source, a.k.a. trigger)
- for performing work inside the app, such as invoking external services
Resources? Triggers?? Operations???
Sigma also associates its resources with your serverless app in a similar fashion:
- A trigger is responsible of, well, triggering the function, and so is associated with the
eventvariable of the function. A good example is an API Gateway endpoint with one of its methods linked to our function via an integration. - An operation is - you guessed it! - an action that can be performed on or using an entity, such as an insert into a DynamoDB table.
In Sigma, a function can have several triggers (as long as the application itself is aware of tackling different trigger event types!), and can contain several operations (obviously).
Yet, they're different.
It is noteworthy that a resource itself is not a trigger or an operation; triggers and operations are associated with resources (they kind of "bridge" functions and resources) but a resource has its own independent life. As a result, a resource can power many triggers (to be precise, zero or more) and get involved in many operations, across many (again, zero or more) functions.
A good example is S3. If you want to write an image resizer function that would pick and process images dropped into a S3 bucket, you would configure a S3 trigger to invoke the function upon the file drop, and a S3 GetObject operation to retrieve and process the file; however, both will point to the same S3 resource, namely the bucket where images are being dropped into and fetched from.
Launch time!
At deployment, Sigma will take care of putting the pieces together - trigger configs, runtime permissions and whatnot - based on which function is associated with which resources, and in which ways (trigger-mode vs operation-mode). You can simply drag, drop and configure your buckets, queues and stuff, write your code, and totally forget about the rest!
That's the beauty of Sigma.
When a resource is "abandoned" (meaning that it is not used in any trigger or operation), it shows up in the "unused resources" list (remember the dustbin button on the toolbar?) and can be removed from the project; remember that if you do this, provided that the resource is a "new" one (rule of thumb: one created in Sigma), it will be automatically removed from your serverless provider account (for example, AWS) during your next deployment!
So there!
if Sigma's resource model (the whole purpose of this article) looks like a total mess-up to you, feel free to raise your voice on StackOverflow - or better still, our GitHub space, FB page or Twitter feed; we would appreciate it very much!
Of course, Sigma has nothing to hide; if you check your AWS account after a few Sigma deployments, you would realize the things we have been doing under the hood.
All of it, to make your serverless journey as smooth as possible.
And easy.
And fun. :)
Welcome to the world of Sigma!
