Scalability Using Docker & AWS Cloud Infrastructure
The scalability test was chosen to run on AWS over other cloud providers and donated time on dedicated servers for several reasons. The following are the services used: - AWS Lambda functions which are used to signal to the transaction blasters and miners to begin
- AWS API Gateway for the docker containers to poll (DoS in most other hosting providers) the Lambda signal to begin the test
- AWS Container Service (Kubernetes) to orchestrate the transaction blasters and the miners
- AWS EC2 to run the container service
- AWS S3 to store the blocks mined by the miners
- AWS IAM to allow flexible management of resources between operators
- AWS Cloud Trail to enable 3rd party audit of services used to run the test (mainly for cost and accounting not necessarily to audit the throughput which is more of a data analysis)
 Amazon gives Komodo blockchain based projects, developers and service providers a sanctioned environment for use by government customers, a pool of workers with industry accreditation, support and turnkey solutions for rapid deployment. The next steps for our scalability test are to create AWS Cloud Formation stacks for anyone to build their dApps on AWS with limitless scalability.
Docker & Developer Journeys If launching a dApp without the operational overhead of managing blockchain infrastructure suits your organizational needs, then a Komodo service provider can partner with you to manage those systems. Starting as a Komodo Ecosystem Developer will soon be a turn-key operation. Komodo docker images are simply a framework to quickly and locally test your dApps and contracts on a locally generated blockchain. It is not designed to resemble your realistic blockchain network because the block generation is controlled by you. It should not be the only environment you should use as a test so we are also creating a workflow for migrating to your own blockchain you can run locally under real network conditions. This local real network conditions workflow can optionally be skipped and you can deploy to a globally running blockchain enabling testing with more users prior to officially launching on your main network. The beauty of this is the simplicity. The deployment of each environment is the same, only the networking parameters differ and the connectivity of users to your dApp. There are no gas charges to calculate and your dApp can run for free no matter how many users, the value can be stored in other parts of the blockchain and you create a faucet contract to interact with your dApp. With docker, we aren't running full VMs. We're running processes, and by limiting the number of processes in a single container we will end up with greater flexibility. We are not running an operating system inside of the container. When Unix executes a command, it begins to look around for executables and library files on within the PATH. When we run these things normally on a machine, the OS tells it to look in specific folders, like /usr/lib/. The libraries are loaded and the program executes. What a container does is tell a process to look somewhere else for those files, like a chroot jail. The container is just looking in a different spot for files and that different spot is what we will distribute – a komodo daemon with the latest crypto conditions for your own blockchain project. Containers, especially those running under Docker, will also have their own networking space. This means that the containers will generally be running on an internal network to the host. Docker provides wrappers for doing port forwarding to the containers and this is another way to communicate securely by proxying and sanitizing requests. A lot of these notes came from the book "Docker for Developers" (O'Reilly link & lean pub link). A very helpful section tells us of "Twelve-Factor Applications" which lays out a set of rules and design decisions that help scalable, cloud-enabled applications be easily developed and deployed. Docker also helps scale applications and run them in the cloud, so they go hand-in-hand. - The command docker run is great for one-off testing or prototyping, but make sure that anything that is being used for real, production work is stored in Docker Compose and in the same images that will be used for Production
- Services should bind to a port, and be accessible over a port. Do not run services over local unix sockets.
- Applications should be thought of as Processes, not as a single entity.
- Anything that can vary between deployments is considered Configuration and should be part of the environment.
- A code should be stored, and tracked, in a version control system.
There is a new #containerisation channel in the Komodo discord because a couple of notary node operators want to standardize on some conventions…because of the advantages a containerized environment creates.
VuePress For Developer Documentation
After compiling documentation throughout the year through our confluence site hosted by Atlassian and a readthedocs theme for sphinx hosted at docs.komodoplatform.com we are following in the footsteps of the VueJS dev team to create the developer journeys. Note: The existing docs site will remain, we are creating developer resources with focus (& polish). For writing a dApp Toolkit, VueJS components have been created from the last couple of weeks to make samples for the new crypto conditions so developers can quickly explore how the dApp flows. By creating Vue components, we can re-use them in the documentation and VuePress treats vue components like first class citizens. Combined with docker deployments, the barrier to blockchain applications will be simple for many front-end developers. VuePress is a SPA (single page application) with built-in support for markdown – which most of our current docs are written in. So we'll be cataloguing the "greatest hits" and making trails for developers to follow. Multilingual capabilities are supported out of the box, so we are keen to engage with non-english speaking coders. The VueJS dev team has a page on why not other software packages to run their documentation, and seeing as they are "eating their own dog food" and delivery a very good project, we are confident VuePress will be a successful implementation and hopefully we can offer some collaboration or testing for them in the meantime. | 
