Hi Dave. First thanks for stepping up to be a guide. I know you guys are unsung heroes and at other times take the brunt of issues.Thank you for the application. To start:
A. From what I ascertain, you will be working to educate, understand the needs of, and onboard large enterprise clients. However, I don't see you mention that you'll be developing any applications on top of the Factom Protocol yourselves. As such, do I understand that you'll be working to funnel these clients to existing and future application providers on the Factom protocol?
Could you elaborate on the above?A seamless failover process is being developed to insulate the end user from any degradation. This will include identifying issues before they cause downtime and preemptively rolling to backups to avoid downtime.
1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.B. Let's say you get an Authority Node. How it performs will be easy to monitor. However, as part of your campaign you promise a lot more which is important despite your 50% Efficiency. The Standing Parties will likely want to see what progress you're making since it was part of your campaign. My questions are:
1. How would you communicate with the Standing Parties. Examples would be blog, twitter, Discord, Reddit, etc.
2. What would you communicate and how often?
3. What metrics should be used to gauge your development progress and success?
As with all start-ups, things can be volatile. They change quickly. Matt O was previously working with a member of another entity. At that time, Jay Cheroske was their lead tech guy. Jay was brought in by the aforementioned member. Jay was responsible for spinning-up and managing servers for Matt, the member, and a handful of other entrepreneurs Matt had brought on board while everyone awaited clarity on how Factom would proceed regarding the Authority Set.C. I noticed that jcheroske is listed on your application as well as another application. Can you explain?
Hi Niels. Please see answers to your other questions for clarification. As specific security and infrastructure guidelines are finalized within the community, we will obviously adapt to agreed-upon best practices.Thank you for your application
Could you elaborate on the above?
Yes - the intention of having two Auth nodes is to allow for live environment swapping in the form of Blue / Green deployments. We want to minimize downtime as much as possible. Please see brainswaps answer.I have a good idea about your infrastructure, but it could use a little more explanation
The two auth instances per region. One is an active Auth node and the other is a follower for Blue/Green deployments and brainswaps? If not could you elaborate?
We wanted to allow for brainswaps between unexpected failures of Auth servers with the followers to minimize downtime as much as possible. The entire intent of the overall architecture is to have a robust and fault tolerant implementation.NK03)
Could you elaborate on the follower instances?
The Google Cloud load balancer will have TCP port 8110 health checks that will determine whether the NATs are up and running. We will also be utilizing the log collection engine depicted to determine anomalies in the backend infrastructure.NK04)
You use a HTTPS loadbalancer. Could you elaborate on the ports you are loadbalancing? What type of algorithm will the loadbalancer use? What is the goal?
Google cloud doesn't provide a managed NAT service like AWS Nat Gateway, but the NAT would sit in front of all public internet traffic and obfuscate those requests from our production Auth and Follower nodes in the private subnet. As it stands today, Google requires the NAT VM to be debian based.NK05)
You are applying NAT. Could you elaborate on the type of NAT you will be using and to what nodes you will be applying NAT?