- What is the deal with "early access"?
The service is not ready for enterprise level traffic yet as there are missing components and performance limits, so here is what developers can expect during "early access": bugs, data loss, poor performance, high error rates.
Much of the service has 100% test coverage, but that only means the code is reachable.
The heart of Adama is a new language, and there may be edge cases which are not well thought out or well tested.
The distributed system is also fresh, but it is baked on well founded principles.
Errors are not yet broken down between "your fault" and "the service's fault".
However, each error does have a unique code which gives plenty of information of where something bad happened and error logs are written to disk.
Some of these errors require additional error handling and investigations.
Furthermore, there is no notion of retry anywhere in the system as retries can mask some problems.
Scale and capacity: Adama is running with a finite set of hosts.
Capacity is easily added to the web and compute tiers, but the data tier is the current bottleneck.
Performance: It's not great, but it's competitive in some markets. As the data tier shapes up, the goal is to find hot spots and eliminate variance.
Heat: As more capacity is added, Adama lacks property capacity placement and rebalancing.
The signals to build this are flowing, but service spikes are not handled well as of now.
A key thing to build is E2E flow control as this will make heat spikes tolerable.
- When will Adama exit "early access"
The key is that the service will be scalable, durable, and fault tolerant with reasonable latency.
This is going to be a journey, and I have no exit date. I will, however, keep you updated via the blog.
The snarky answer is "Why not?", but the many answers to
why does Adama exist have been covered at length within the history section of the Adama book.
The good question of Why you should be interested in Adama?
This is hard, and the generic nature of Adama doesn't help as it creates a vast possible spectrum of answers.
The next question answers what use-cases which will help you decide if Adama is a fit for you.
The good new is that Adama doesn't require a lengthy contract, and the only thing we ask is that you risk some time to find out if Adama is right for you.
- What are some use-cases of Adama (beyond online board games)?
Adama is generic enough to provide: chat, publish-subscriber, real-time notifications, internet of things, collaborative documents, real-time games, and many more.
The answer to what this thing is vast due to the implicit trinity of compute, storage, and networking.
For a more detailed answer, there is an entire chapter outline what Adama is within the book.
The book also has examples of some of these use-cases in action.
- Can infrastructure for board games be trusted for an enterprise business?
This infrastructure is over-engineered for board-games, but it was designed to be operated within fortune-100 enterprises.
The creator has a decade of experience building infrastructure that you or your family rely on within two fortune-100 enterprises.
- Why is Adama a platform rather than a framework?
This has a long answer which is only touched on by the top five secrets of adama programming language,
but the short answer is due to the limits of various languages and some of the unique requirements desired for building online board games. Here is a short summary of what Adama enables:
(1) rewind the entire state,
(2) an audit history of who did what and what,
(3) treat a single document like a relational databases because relational databases are super awesome,
(4) have await/async semantics which operate with rewind and interruptions,
(5) document layout with privacy defined reactively,
(6) leverage time to drive document state and behavior,
(7) a relentless focus on the game logic.
By building Adama as a platform, we bring serverless super-powers to the web such that you need fewer things total.
- What is a brick-hour?
A brick represents a unit of compute combining memory, cpu, concurrent connections, and message passing.
At core, a brick is designed to reflect the realities of cloud computing rather than metering every interaction.
This model is designed to be fair by billing you on the resource you use the most.
Ideally, this pricing should be low such that you benefit more, and our profit is driven by seeking efficiency wins across multiple customers.
- What resources come with a brick-hour?
Every brick comes with X messages, Y connections, Z MB of memory, and W compute units. We don't have these values yet because are still in early access.