Heroku Architecture Designer LATEST SOLUTION 2023 EDITION GUARANTEED GRADE A+

Buildpacks Responsible for transforming deployed code into a slug which can then be executed on a dyno. Build packs are composed of a set of scripts and depending on the programming language, the scripts will retrieve dependencies, output generated assets or compiled code, etc. Custom build packs for other languages are available but not supported. Officially Supported Buildpacks PPPGGG JC SNR Ruby N Clojure Python Java Gradle Gradle 3.x Scala Play 2.x PHP Go Slug Compiler Slugs are compressed and pre-packaged copies of your application optimized for distribution to the dyno manager. When you push code to Heroku, code is transformed into a slug. Slug compilation is limited to 15 minutes Slug Compilation Steps 1. Create a fresh checkout of HEAD from Master Branch 2. Remove anything related to .slugignore 3. Download, build and install local dependencies as specified in build file ( 4. Package the final slug archive Dyno Configurations 1. Web Web process type defined in procfile. Only web dynos receive HTTP traffic from routers. 2. Worker Any "non-web" processes defined in your procfile. Used for background jobs, queueing systems, and timed jobs. Can have multiple worker dynos in your app. 3. One-off Temporary dynos that can run detached or with their input/output attached to your local terminal. Scaling Dynos Horizontally/Scale Out - For example adding more web dynos allows you to handle more concurrent HTTP requests Vertically/Scale Up - Use bigger dynos. This effects the maximum amount of RAM available to your application. Dyno Redundancy Applications with multiple running dynos will be more redundant against failure. If some dynos are lost, the application can continue to process requests while the missing dynos are replaced. Dyno Security Dynos are strongly isolated from one another for security purposes. Heroku uses OS containerization with additional custom hardening to ensure that access is properly restricted for all customers. SIGTERM shutdown When the dyno manager restarts a dyno, the dyno manager will request that your processes shut down gracefully by sending them a SIGTERM signal. The application processes have 30 seconds to shut down cleanly. During this time they should stop accepting new requests or jobs and attempt to finish their current requests or put back other worker processes to handle. Dyno Memory/Dyno Types Free, Hobby, Standard-1x standard-2x performance-m performance-l private-s private-m private-l Free, Hobby, Standard-1x = 1GB standard-2x = 2GB performance-m = 5GB performance-l = 28GB private-s = 1 GB private-m = 2.5 GB private-l = 14GB Using a dyno type that is too small might cause constant memory swapping, which will degrade application performance. Application metrics data, including memory usage, is available via the Metrics tab of the Heroku Dashboard. Dyno Optimization - CPU Most applications are not CPU-bound on the web server. If you are processing individual requests due to CPU or other shared resource constraints, then optimizing concurrency on the dyno may not help your applications throughput. In other words, if you r application is slow when there is little, traffic, then you should address that issue first before changing dyno types to include more CPU cores. Dyno Optimization - RAM Depending on language and web framework, there is typically a direct correspondence between RAM and concurrency. For example, web servers like Unicorn for Ruby or Gunicorn for Python pre-fork a number of identical copies of your web servers (called workers). Unicorn has its own connection queue and as workers finish a web request, they pull a new request off the queue. Basic Methodology for Optimizing Memory 1. Use a concurrent web server 2. Set up instrumentation to measure the impact of load on the app 3. Observe the app's performance, and adjust the concurrency as necessary Measuring Memory and Throughput log-runtime-metrics in log stream Librato New Relic Heroku Button Enables users to deploy apps to Heroku without leaving the web browser and with little or no configuration Heroku Requirements Valid file in the root directory App source code hosted in GitHub repository **Heroku Button will not work with repos that have Git submodules Adding the Heroku Button Once you've verified that your file is valid and working, you add the button to your repo README Two ways of referencing the template: - Resolve the template implicitly - useful for GitHub documentation - Explicit template parameter that points to the repo - useful for buttons sitting outside of the GitHub repo Example Implicit: a href=" img src=" /a Example Explicit a href=" img src=" /a Parameterizing Buttons You can supply URL paramaters in the Button URL to override values for environment variables Example: Postgres Follower Databases A database follower is a read-only copy of the leader database that stays up-to-date with the leader database data. As writes and other data modifications are committed in the leader database, the changes are streamed, in real-time, to the follower databases. Seems like this is a good option as a reporting-only database. Followers are only supported on Standard, Premium, Private and Shield tier database plans. Follower must be able to accommodate the current data volume of the leader database. If an attempt is made to create a follower that cannot accommodate the data volume, there will be an error and the follower will not be created. Follower Lag Considerations The lag between a leader and follower databases varies greatly depending on the amount and frequency of data updates. It is possible for long running queries on the follower to increase your lag time, though once those queries are done your follower should catch up. CONTINUED...