Currently, we only offer compute, however, we have plans to add Mongo noSQL and PostgreSQL databases soon-ish. And later file storage and caching.
No. One of the advantages of Merrymake is that we make sure the images are up to date, and don't have security issues in them. Another reason is that we need to inject our caching mechanism, which wouldn't be possible for all images.
The message queues serve two purposes, first and foremost they start service instances, therefore they are essential. Furthermore they decouple caller and callee making it much easier to split a service into seperate repositories/deployment units if they grow too large. Because it is easy to split services we can postpone the decision of how to split our code to the latest possible time.
Following the Twelve-Factor App guidelines there should be only one mechanism for concurrency in a system. In Merrymake, concurrency is achieved through posting multiple messages to the Rapids. This design simplifies the individual services making them easier to maintain. Combined with our advice of using row-immutable data stores we can avoid most of the complexity of distributed systems.
The pipeline includes a smoke test, run in a production-identical environment, where we can ensure files and third-party connections are available, and stop the deployment if not. Since the service is allowed to execute custom code during this phase we can add any checks we'd like.
With that said, the built-in pipeline should be thought of as a deployment pipeline, not an integration pipeline. This pipeline is likely sufficient for a young project, but as the code matures we probably want to add more testing and static analysis. Through the Git protocol Merrymake integrates well with all CI/CD platforms, including GitLab, Azure DevOps, GitHub, and BitBucket.
Regarding a DEV environment Merrymake comes with a simulator that can spin up any part of the system, and simulate how it would behave in the cloud. This simulator allows developers to test and debug their code locally (even offline) before pushing it to production.
With regards to TEST and STAGING, Merrymake aims to promote the current best-known practices for software development. Using simple feature toggling we can expose some functionality to specific users and not others, giving us the same behavior as multiple environments, without the downsides of trying to keep two or more environments in sync.
Security is paramount for a platform like ours, and although absolute security is impossible we do everything possible to protect our customers data and uptime.
Merrymake is designed with scale in mind, so the platform simply starts more instances to handle the increased traffic up to our hardware limit. As our usage grows, vulnerability to this type of attack shrinks for all our customers. Of course third-party services like databases might struggle under the increased presure. You can limit how many parallel instances you want in Merrymake.
The Merrymake CLI and Git use SSH for all communication, ensuring that users are authentic and no-one can listen in on the traffic.
Our no-code interface relies on a magic link sent to an email, and so if the email is secure so is the magic link and thus the no-code interface.
On top of both is Merrymake's access control where you can specify exactly which users have access to which features.
The most sensitive information is secret envvars, such as database connection strings. In Merrymake these are encrypted end-to-end, meaning they are encrypted on the developer's device and only decrypted inside the container running the code. Only this container has access to both the key and the encrypted value, thus only developers in your organization can possibly get this information. The platform also prevents displaying this information, to avoid accidental leaking, although this can be circumvented by intentionally malicious developers in your organization.
The next level of sensitivity is messages in-transit, which are also encrypted. Message payloads are treated as byte streams, and so these can be encrypted as well for additional security, however this is not done by the platform.
Finally, since speed is one of our primary objectives, on the critical path -- between request and response -- most things are stored as plaintext. That includes source code (may change later), non-secret envvars, and the event.
