What are the responsibilities and job description for the Systems Developer position at Tech Army?
Project:
The Farm Phosphorus Reduction Planner (FarmPREP) is an innovative web application that
streamlines data inputs and outputs to USDA-NRCS's complex Agricultural
Policy/Environmental eXtender (APEX) model to provide accurate results for phosphorus
loading from agricultural fields. FarmPREP combines the integrity of the APEX model with a more efficient user-interface to determine phosphorus loading in Vermont. FarmPREP is fully
functional, free for users, simple to use, and has been calibrated to common agronomic practices
in Vermont. FarmPREP was created by and is currently maintained by a contractor.
Shapefiles of fields are uploaded or drawn in FarmPREP directly for each farm. Crop
management inputs for each field (e.g., crop rotations, tillage, nutrient applications, conservation
practices and optional soil and manure test results) are combined with geospatially determined
soils, slope and climate data to determine edge of field phosphorus loss through sheet and rill
erosion. APEX runs simulations for the inputs over a 30-year period to account for climate
variability and FarmPREP outputs the annual average phosphorus load (lb P/ac/yr). Users can
also specify target phosphorus reductions and FarmPREP will model the top 10
practice/management changes per field to achieve the target. Results from multiple scenarios can
be viewed together for comparison.
The Vermont Agency of Agriculture, Food & Markets (VAAFM) previously received funding to
modify the FarmPREP software to be utilized for VAAFM's Vermont Pay-For-Performance
(VPFP) program, which pays farms on a pound per acre basis of phosphorus loss modeled in
FarmPREP. VPFP has been utilizing FarmPREP for the last 5 years and is entering its next 5-
year phase, which entails FarmPREP modification as the VPFP program evolves. A complete
task list is provided below.
Current Environment of FarmPREP:
FarmPREP is a custom-built tool that combines web-based technology and the United States
Department of Agriculture (USDA) Agricultural Policy Environmental eXtender model (APEX)
(Steglich et al., 2016).
FarmPREP runs using a hybrid N-tier configuration of virtual servers, at Amazon AWS, that
includes a web server, middleware (API) server, a separate model API server, and a PostGreSQL
database server, as well as a Docker container system executed on AWS Fargate.
All of the servers are operated with a commercially supported Linux-based OS, and, aside from
the Esri ArcSDE components in the PostGreSQL database, use open-source software.
Of the four servers in the FarmPREP deployment, each plays a different role, and separates
duties so that the system can be more resilient and scalable.
" Web Server: The web server is used to run the Apache web server service that responds to
requests from the internet for FarmPREP. The server has 2 virtual CPUs, is assigned 1gb of
RAM, and has 20gb of storage.
" Main API Server: The API server runs a custom-built NodeJS based middleware ReST API
that allows the HTML/Javascript running in the user's web browser (the front end) to connect
to and interact with the database on the backend. The server has 2 virtual CPUs, is assigned
2gb of RAM, and has 20gb of storage.
" Database Server: The database server runs a standard instance of PostGreSQL that can only
be connected to by the API servers. The PostGreSQL database is enabled with ArcGIS
Enterprise Geodatabase functionality (formerly known as ArcSDE) as well as PostGIS functionality. The database server currently runs PostGreSQL v12 with ArcGIS Enterprise
Geodatabase components at v10.9.1. The server has 8 virtual CPUs, is assigned 15gb of
RAM, and is assigned 250gb of storage.
" mPipe API Server: A second API server, called the mPipe server, is responsible for
managing the APEX model running process. This server runs a custom NodeJS ReST API,
like the Main API Server, but also takes on communication with the AWS Fargate service, as
well as running various Python scripts. The server has 2 virtual CPUs, is assigned 8gb of
RAM, and has 20gb of storage.
The four servers are setup and held inside of a Virtual Private Cloud that enables them to
communicate with each other using private IP addressing, while exposing only the web and API
servers to the internet via ports 80 and 443 (where port 80 in the application kicks the user over
to use port 443 to enforce SSL use).
APEX Containers: Separate from the servers is the containerized APEX system. A Docker
container template has been created for Farm-PREP that runs the Linux compiled APEX model.
The container is pre-packaged with much of what it needs to run the model. However, every time
a container instance is created from this template, it is given input parameters that inform the
container on how to customize the APEX run based on user inputs and field-specific
information. Once the container instance starts running it uses a unique ID and connects back to
the main PostGreSQL database to fetch these details for the APEX run. Python scripts are run on
the container instance to generate site/user specific input files that APEX needs before it is
executed. Once APEX is run, the resulting outputs are returned to the database, and the output
files are compressed into a single file that is uploaded to AWS before the container instance
stops running and disappears. The containers are executed inside of AWS Fargate, which allows
the system to run thousands of container instances simultaneously, if necessary (or sometimes
just run 1 or 2 instances), therefore enabling a massive time savings from running the APEX
model runs sequentially.
The following technical requirements for each of the primary components of FarmPREP are
listed below.
" Front-end:
o HTML5
o SCSS
o Esri ArcGIS Javascript API
o Angular
" Middleware Main API & mPipe API:
o NodeJS
o Linux
" Backend:
o PostGreSQL/PostGIS
o Linux
o Apache2
" APEX:
o The APEX model's code is maintained by Texas A&M
o Docker
o Python
o Linux
o AWS S3
Amazon Web Service (AWS) ECS/ECR & Fargate
Authentication
1. Login is routed through the State's central identity provider login page Okta for external
users, Entra for internal users ensuring state-approved authenticators and user
experience.
2. Authentication for both internal and external users is handled via SAML 2.0 or OIDC only,
and in conformance with their respective standards.
3. Authentication is validated in DEV and TEST environments, in addition to PROD, when
directed by the State.
4. Applications serving both internal and external users support two identity providers with
separate URLs. Where an application cannot support two providers, the State may agree to
handle routing through a single IDP upon request.
5. Applications dependent on internal/external user status can reliably determine that status
from OIDC claims or SAML attributes.
The Farm Phosphorus Reduction Planner (FarmPREP) is an innovative web application that
streamlines data inputs and outputs to USDA-NRCS's complex Agricultural
Policy/Environmental eXtender (APEX) model to provide accurate results for phosphorus
loading from agricultural fields. FarmPREP combines the integrity of the APEX model with a more efficient user-interface to determine phosphorus loading in Vermont. FarmPREP is fully
functional, free for users, simple to use, and has been calibrated to common agronomic practices
in Vermont. FarmPREP was created by and is currently maintained by a contractor.
Shapefiles of fields are uploaded or drawn in FarmPREP directly for each farm. Crop
management inputs for each field (e.g., crop rotations, tillage, nutrient applications, conservation
practices and optional soil and manure test results) are combined with geospatially determined
soils, slope and climate data to determine edge of field phosphorus loss through sheet and rill
erosion. APEX runs simulations for the inputs over a 30-year period to account for climate
variability and FarmPREP outputs the annual average phosphorus load (lb P/ac/yr). Users can
also specify target phosphorus reductions and FarmPREP will model the top 10
practice/management changes per field to achieve the target. Results from multiple scenarios can
be viewed together for comparison.
The Vermont Agency of Agriculture, Food & Markets (VAAFM) previously received funding to
modify the FarmPREP software to be utilized for VAAFM's Vermont Pay-For-Performance
(VPFP) program, which pays farms on a pound per acre basis of phosphorus loss modeled in
FarmPREP. VPFP has been utilizing FarmPREP for the last 5 years and is entering its next 5-
year phase, which entails FarmPREP modification as the VPFP program evolves. A complete
task list is provided below.
Current Environment of FarmPREP:
FarmPREP is a custom-built tool that combines web-based technology and the United States
Department of Agriculture (USDA) Agricultural Policy Environmental eXtender model (APEX)
(Steglich et al., 2016).
FarmPREP runs using a hybrid N-tier configuration of virtual servers, at Amazon AWS, that
includes a web server, middleware (API) server, a separate model API server, and a PostGreSQL
database server, as well as a Docker container system executed on AWS Fargate.
All of the servers are operated with a commercially supported Linux-based OS, and, aside from
the Esri ArcSDE components in the PostGreSQL database, use open-source software.
Of the four servers in the FarmPREP deployment, each plays a different role, and separates
duties so that the system can be more resilient and scalable.
" Web Server: The web server is used to run the Apache web server service that responds to
requests from the internet for FarmPREP. The server has 2 virtual CPUs, is assigned 1gb of
RAM, and has 20gb of storage.
" Main API Server: The API server runs a custom-built NodeJS based middleware ReST API
that allows the HTML/Javascript running in the user's web browser (the front end) to connect
to and interact with the database on the backend. The server has 2 virtual CPUs, is assigned
2gb of RAM, and has 20gb of storage.
" Database Server: The database server runs a standard instance of PostGreSQL that can only
be connected to by the API servers. The PostGreSQL database is enabled with ArcGIS
Enterprise Geodatabase functionality (formerly known as ArcSDE) as well as PostGIS functionality. The database server currently runs PostGreSQL v12 with ArcGIS Enterprise
Geodatabase components at v10.9.1. The server has 8 virtual CPUs, is assigned 15gb of
RAM, and is assigned 250gb of storage.
" mPipe API Server: A second API server, called the mPipe server, is responsible for
managing the APEX model running process. This server runs a custom NodeJS ReST API,
like the Main API Server, but also takes on communication with the AWS Fargate service, as
well as running various Python scripts. The server has 2 virtual CPUs, is assigned 8gb of
RAM, and has 20gb of storage.
The four servers are setup and held inside of a Virtual Private Cloud that enables them to
communicate with each other using private IP addressing, while exposing only the web and API
servers to the internet via ports 80 and 443 (where port 80 in the application kicks the user over
to use port 443 to enforce SSL use).
APEX Containers: Separate from the servers is the containerized APEX system. A Docker
container template has been created for Farm-PREP that runs the Linux compiled APEX model.
The container is pre-packaged with much of what it needs to run the model. However, every time
a container instance is created from this template, it is given input parameters that inform the
container on how to customize the APEX run based on user inputs and field-specific
information. Once the container instance starts running it uses a unique ID and connects back to
the main PostGreSQL database to fetch these details for the APEX run. Python scripts are run on
the container instance to generate site/user specific input files that APEX needs before it is
executed. Once APEX is run, the resulting outputs are returned to the database, and the output
files are compressed into a single file that is uploaded to AWS before the container instance
stops running and disappears. The containers are executed inside of AWS Fargate, which allows
the system to run thousands of container instances simultaneously, if necessary (or sometimes
just run 1 or 2 instances), therefore enabling a massive time savings from running the APEX
model runs sequentially.
The following technical requirements for each of the primary components of FarmPREP are
listed below.
" Front-end:
o HTML5
o SCSS
o Esri ArcGIS Javascript API
o Angular
" Middleware Main API & mPipe API:
o NodeJS
o Linux
" Backend:
o PostGreSQL/PostGIS
o Linux
o Apache2
" APEX:
o The APEX model's code is maintained by Texas A&M
o Docker
o Python
o Linux
o AWS S3
Amazon Web Service (AWS) ECS/ECR & Fargate
Authentication
1. Login is routed through the State's central identity provider login page Okta for external
users, Entra for internal users ensuring state-approved authenticators and user
experience.
2. Authentication for both internal and external users is handled via SAML 2.0 or OIDC only,
and in conformance with their respective standards.
3. Authentication is validated in DEV and TEST environments, in addition to PROD, when
directed by the State.
4. Applications serving both internal and external users support two identity providers with
separate URLs. Where an application cannot support two providers, the State may agree to
handle routing through a single IDP upon request.
5. Applications dependent on internal/external user status can reliably determine that status
from OIDC claims or SAML attributes.