What You Need To Know To Pass The Heroku Architecture Designer Exam

​​Well it finally happened. I failed a Salesforce exam. My first failure other than a few maintenance exams back in the day. I had thought about canceling my exam the night before, I knew I wasn’t quite ready. But in following my own advice, I wanted to keep the date. If I failed, I failed…so be it. I’d learn something from the experience either way.
​
​Once I started the exam my my suspicions were confirmed...I wasn't ready. Things like which features are only available in Heroku Enterprise, and why you would want to use Heroku Redis instead of Postgres left me scratching my head. 

Here was how I fared on my first attempt:
​

My Section-Level Scoring:

• Heroku Platform: 83%
• Data: 60%
• Security: 88%
• Heroku Enterprise: 41%
• Architecting Applications: 77%
• Integrations: 55%

Actual Exam Ranking:

• Heroku Platform: 10%
• Data: 17%
• Security: 15%
• Heroku Enterprise: 28%
• Architect Applications: 15%
• Integrations: 15%

​What a rookie mistake! Based on my score I hadn’t focused enough on the content (Heroku Enterprise) that was weighted the heaviest. How did I manage to do this? I know better….right?

Well, as it turns out, that there were a few core reasons why I came up short in the most important topic on the exam. The first is that Heroku Enterprise is not available to get hands-on with. So if you haven’t worked in an org that uses this version, you can’t get your hands on it. The second (and most important) reason was that I didn’t have a good enough scaffolding to hang all the different pieces of knowledge I was trying to understand. The Trailhead trailmix for the Heroku Designer exam is essentially a lot of links to the Heroku developer docs. Since they are so detailed, I was getting lost in the weeds without seeing the big picture concepts. 

In studying for my retake, I was able to create a framework for me to truly understand the different aspects of Heroku, including Heroku Enterprise. Here’s what I learned:
​

Common Runtime vs. Private Spaces

Common Runtime

• Multi-tenent
• When you create an app in the Common Runtime you choose a region of either US or Europe
• In the common runtime dynos can’t talk to eachother (each dyno is secured with strong firewall rules to ensure isolation)
• Outbound requests from your apps come from IP addresses that are NOT stable/consistent

Private Spaces

• Single-tenent
• Only available in Heroku Enterprise (boo! you can’t play with the features)
• When you do have Enterprise you create the new space from the dashboard (Q: who can create private spaces?? A: only team admins can create, destroy or modify a PS)
• You pick the region when creating a private space (dublin, frankfurt, oregon, sydney, tokyo, virginia)
• The region can’t be changed after the space is created
• All apps created in a Private Space are in the same region
• Private spaces are HIPPA and PCI compliant
• Each private space has an AWS account dedicated to you
• Each space is built inside a new VPC (virtual private cloud on AWS)
• Postgres & Redis can run inside each private space (which means that your data doesn’t get exposed over the public internet)
• There are two “flavors” of Private Spaces : Standard and Shield

To Summarize, Here are The Special Features of Standard and Shield Private Spaces

• Dedicated environment for running apps and certain add-ons w/in an isolated network
• Outbound requests from apps in Private Spaces originate from a set of stable IP addresses (which allows you to securely communicate w/white listed services on-prem or on other networks)
• Best when there are strict requirements for data protection 

Special Features of Shield Private Spaces

• Strict TLS enforcement
• Shield Dynos
• Shield Postgres
• You can send all logs to a single Http drain (aka private space logging)
• TSL1.0 can’t be used
• Interactive dyno console sessions (heroku run bash) are encrypted with SSH (secure socket shell), you must register an SSH key with your Heroku account
• Shield Heroku Connect
• Keystroke logging of prod bash sessions

​Features of Private Spaces That Let You Securely Communicate And Share Data

​
Internal Routing
On creation, apps in Private Spaces can enable Internal Routing. Unlike other apps, apps with Internal Routing cannot receive external web traffic to their web process type. Instead, their web process type can receive traffic from:

• Your other apps running in the Private Space network
• Software running in VPC-peered or VPN-connected networks
• In all other ways, apps with Internal Routing behave exactly like other Private Space apps.

Internal Routing is useful for:

• APIs and other secure microservice components that are consumed solely by your other Private Space apps and software running in a peered AWS VPC.
• Apps that are accessible only to users on a VPN-connected, on-prem network. Requests to apps can originate only from hosts on the private network, and requests and responses can only transit the IPSEC connection.

Internal Routing is great for Heroku customers that want to publish HTTP apps, APIs and services for internal-only consumption from within a Private Space (and connected networks). It's another feature that makes Heroku “Better Together” with existing enterprise systems deployed on-prem or on AWS.

Heroku Private Spaces can configure a connection to another private network using IPSec VPN. This lets dynos connect to hosts on your private networks and vice versa. Connections are established over the public Internet, but all traffic is encrypted using IPSec.
Currently, only one VPN connection (with two redundant tunnels) is supported per Private Space.


Private Space Peering

• Private Space Peering enables you to establish a private network connection between dynos running in a Heroku Private Space and an AWS VPC you control. This connection does not traverse the public Internet.
• Private Space Peering enables you to establish a private network connection between dynos running in a Heroku Private Space and an AWS VPC you control. This connection does not traverse the public Internet.
• You cannot create a VPC peering connection between VPCs that have matching or overlapping IPv4 or IPv6 CIDR blocks
• Connections to web processes in a Private Space on appname.herokuapp.com or a custom domain name are made over the public Internet, not the peering connection.
• You can only connect to IP addresses in your VPC that are part of the primary CIDR block. If you have added secondary CIDR blocks to your VPC, they will not be reachable from the Private Space.
• You can connect from your VPC to dynos in the Private Space, but you must know the IP address in advance. Dynos do not have public DNS records.
• You cannot connect directly to data services such as Postgres, Kafka or Redis in the private space from the peered VPC.
• Dynos cannot connect directly to other networks that are peered to your VPC. Instead, you need to run a proxy or load-balancing service inside your VPC to enable such connections.
• You can peer up to 5 AWS VPCs to a private space.* Open a support ticket if you need to peer more than 5 VPCs to your private space.
• TLDR; Peering only works with a VPC, not VPN and you can't have overlapping CIDR blocks when you peer.

Private Space DNS Service Discovery
How processes in a private space can communicate with one another!

Processes running in Heroku Private Spaces can communicate easily with one another by using DNS Discovery to obtain the IP address of other dynos in the same space. This makes it easy to create and deploy microservices. For example, suppose you want to create an image-processing app that consists of several small services, including:

• A web process for accepting jobs
• A worker process for processing incoming images
• An agent process for handling back-office interactions

With DNS Service Discovery, processes in systems like this have a simple way to reach one another to perform tasks. When the web process accepts a new job, it can alert the back-office service via its DNS name that a new job has arrived. It can then send the job to the worker process via its DNS name as well.

Unlike dynos in the Common Runtime, dynos in Private Spaces can freely exchange TCP and UDP traffic on a private network. A process type of any kind (web or worker) can choose to listen on any available port, and other dynos in the space can connect to that port on the dyno host.

To communicate with another process, you need to know the IP address of the dyno(s) the process is running on, along with the port number the process is listening on. Typically you know the port number in advance, because server processes listen on a fixed port number. It is not possible, however, to know the dyno’s IP address in advance. To resolve this, Heroku provides a DNS-based naming scheme for dynos. This lets you find and connect to any dyno in a Private Space by specifying:

• The name of the process’s associated Heroku app
• The process type (such as web or worker) of the process you want to connect to
• Optionally, the dyno number to connect to (useful when a process is running on more than one dyno)

​Kafka, Redis and Postgres

​Heroku Postgres + Private Spaces

• Private and Shield spaces each have their own set of Heroku Postgres Plans that are unique to that type of space.
• They are designed for apps that can tolerate up to 15 minutes of downtime in a given month
• Private Tier Features - no row limits, rollback up to 7 days, high availability, automatic encryption-at-rest of all data written to disk, database metric published to app log stream
• Shield Tier features- essentially the same. 

Shield Tier Postgres should be used when meeting compliance is a goal of your app and business. Shield Tier Postgres DBs  have the following restrictions:

• Non-TLS (Transport Layer Security) connections from dynos to Shield databases are not possible. Encrypted connections are always enforced.
• Dataclips cannot connect to Shield databases
• Shield databases do not allow connections via heroku pg:psql from outside the Private Space
• Direct access via “Trusted IPs” is not allowed for Shield databases from outside the Private Space
• Shield databases are monitored by additional intrusion detection and host scanning mechanisms
• PGBackups will not work with Shield databases
• Private or Shield Postgres DBs are only available in the Private Space they are connected to (see diagram below)

Apache Kafka Topics
All Kafka messages are organized into topics. If you wish to send a message you send it to a specific topic and if you wish to read a message you read it from a specific topic. A consumer pulls messages off of a Kafka topic while producers push messages into a Kafka topic. Lastly, Kafka, as a distributed system, runs in a cluster (For more on Kafka Clusters: https://www.tutorialspoint.com/apache_kafka/apache_kafka_cluster_architecture.htm. Each node in the cluster is called a Kafka broker.

Kafka topics are divided into a number of partitions. Partitions allow you to parallelize a topic by splitting the data in a particular topic across multiple brokers — each partition can be placed on a separate machine to allow for multiple consumers to read from a topic in parallel. Consumers can also be parallelized so that multiple consumers can read from multiple partitions in a topic allowing for very high message processing throughput.

Each message within a partition has an identifier called its offset. The offset the ordering of messages as an immutable sequence. Kafka maintains this message ordering for you.

Apache Kafka Partitions

Topics are comprised of some number of partitions. Each partition will contain a discrete subset of the events (or messages, in Kafka "speak") belonging to a given topic.

Modifying the number and usage of these partitions is important to tuning your Kafka for your product, and for balancing ordering, parallelism, and resilience concerns.
The following are the key properties to balance when evaluating the partition structure for use with a given topic.

• Message ordering - Messages within a given partition will be strictly ordered, but this ordering is not guaranteed across partitions.
• Consumer group parallelism - A consumer group can have as many parallel consumers of a topic as there are partitions in the topic.
• Resource utilization - High numbers of partitions can increase the resource utilization and time to recover or re-elect leaders when brokers are recovering from failure.

Producers may choose arbitrary logic for sending messages to the partitions within a topic, using basic hashing for even distribution, or specific logic to maintain ordering and throughput semantics for a given product’s needs.

Heroku Redis

• An in-memory key-value store, NOT a relational database
• All premium Redis plans come with High Availability (HA) feature.
• When the primary Redis instance fails, it is automatically replaced with another replica, called a standby
• HA standbys are physically located in different availability zones to protect agains availibility-zone-wide failures

​Use cases for Redis:
Job Queues, API Rate Limiting, Session Storage, Share Resources between processes, caching
​

Data Clips

Heroku Dataclips enables you to create SQL queries for your Postgres database and share the results with colleagues, 3rd party tools and the public. Recipients of a dataclip can view the data in their browser and also download it in JSON and CSV formats.

Dataclips cannot be used in:

• Shield databases
• Outside the private space via trusted IPs

A dataclip is default published and can be viewed and edited by all collaborators on the app the database belongs to. If you don’t want collaborators to have access you can change the dataclip status to draft. If the app is owned by an Enterprise Team, the user must also have the deploy or operate permissions. In all cases, the user must have access to the default credential for the database

Limits and Timeouts

• Limit is 100K rows
• Times out after 10 minutes
• Unauthenticated .csv or .json endpoints are limited to 30 requests per IP per minute

You can share dataclip results. This does not expose the query or data about the underlying database.

Sharing with Public

• Click Create public view
• User Does not need to auth w/Heroku login
• To replace existing public URLs, revoke and then recreate

Download and Export

• Dataclips can be downloaded and exported in CSV or JSON
• To enable 3rd part access, copy either the JSON or CSV URL (whichever is expected). These URLs contain an access token that permits access to the dataclips result w/out auth. Keep these secret!! Click refresh access token to invalidate
• When a database moves to a different version of Postgres, dataclips is orphaned

Dataclips execution vs. view

• When viewed or downloaded it will execute query again if not run in last 60 seconds (but will return last execution)
• If you keep the browser open, the results refresh every one to 2 minutes

​Logging

​Logplex
Heroku’s Logplex router is responsible for collating and distributing the log entries generated by your app and other components of the Heroku platform. It makes these entries available through the Logplex public API and the Heroku command-line tool.

In a distributed system such as Heroku, manually accessing logs spread across many dynos provides a very disjointed view of an application’s event stream and omits relevant platform-level events. The Logplex facility solves these issues in an accessible and extensible manner. Logplex routes messages from sources to drains.

Note: Private Space Logging does not use Logplex.

Log sources are any processes that might want to emit log entries relevant to your app. Some examples: your web dynos, the Heroku platform, the Heroku routing stack, and many add-ons.

Log drains are any network services that want to consume your app’s logs, either for automatic processing, archival, or human consumption. Examples include the Heroku command-line tool and several log-processing and management add-ons.

​Diagram illustrating logplex sources and drains

​
The Logplex router resides in Heroku’s us region. Consequently, an app’s logs pass through infrastructure in the United States, regardless of which region the app itself resides in. Apps with strict compliance requirements for log routing can use Shield Private Spaces and Private Space Logging to route logs without using Logplex.


Keystroke Logging

• Only available in Shield
• Can’t be enabled after a Private Space has been created
• All user keystrokes typed into interactive Heroku run sessions are logged

Private Space Logging

• Only available in Shield Private Spaces
• Log is captured at the space level instead of the app level
• All log events from apps , Heroku Postgres dBs and Heroku system services in the space are forwarded to a single log capture destination.
• Only admins can set and change the space logging config
• You can’t turn on private space logging after a space has been created, but you can change the Log Drain URL later

​Heroku Bits and Baubles

Locking an app

• Enterprise team admins and users with manage permission on an app can “lock” the app to freeze app access.
• Locking an app prevents any newly added team users from being able to view the app’s details
• If an app is locked, new team users must be explicitly added to it and granted applicable permissions
• Locked apps are displayed with a lock icon in your team’s list
• Team members are automatically given view permissions to all unlocked apps
• Team admins and users with manage permission for a locked app can grant users app specific permissions for that app
• Locking/unlocking only available in enterprise teams
• Good to lock prod so unexpected folks can’t get access

2FA

• Available in all plans. 
• 2FA adds an extra layer of security by asking for verification code after you sign in with email and password
• The verification code is generated by an app on your smartphone (like Google Authenticator or Authy)
• It’s recommended for all users 
• Enabling 2fa will log you out of all but the current session and regenerate your API key
• SSH based Git push is not affected

​Load Testing Guidelines 

• 10K> in common runtime need heroku approval
• <10K in common runtime don’t need approval
• Private spaces don’t need approval but might need to warm IP

SSL For Heroku Apps
Secure Sockets Layer! 

Ways to enable (in order of most preferred to least)

• ACM - Automated Cert Management
• Heroku SSL (if you need wildcard domains or EV certs)
• SSL Endpoint (paid add on)  only use if:
  • Your app needs to disable TLS 1.0 or 1.1
  •  Your app needs to support older browsers that do not support SNI (Server Name Indication)
  •  You must upload and rotate your own certs

Special notes for Private Spaces:

• Recquire TLS connections to use the SNI extension
• After enabling SSL for cusotm domains, the default app donmain (appname.herokuapp.com (http://appname.herokuapp.com/)) will work on HTTP but will NOT work on HTTPS
• Migrating from the SSL Endpoint addon to Automated Certificate Management requires a DNS change. However, you can use Heroku SSL (SNI) as an intermediate step to avoid downtime for your custom domain.

Dyno Types

• Standard (1x vs 2x)
• Performance
• Private
• Shield

Guide for choosing the right dyno: https://devcenter.heroku.com/articles/optimizing-dyno-usage

Scaling Dynos 
Singleton process types, such as a clock/scheduler process type or a process type to consume the Twitter streaming API, should never be scaled beyond a single dyno. These process types don’t benefit from additional concurrency and in fact they will create duplicate records or events in your system as each tries to do the same work at the same time.

Docker in Heroku

• Heroku provides two ways for you to deploy your app with Docker:
• Container Registry allows you to deploy pre-built Docker images to Heroku
• Build your Docker images with heroku.yml for deployment to Heroku

Google Cloud Platform vs AWS

• Google Cloud Platform is essentially a public cloud-based machine whose services are delivered to customers on an as-you-go basis, by way of service components.
• A public cloud lets you leverage its resources to empower the applications you build, as well as to reach a broader base of customers.
• Although Google does offer a virtual machine hosting service similar to, and competitive with, Amazon Web Services, its primary service model is based around the development and deployment of more modern, containerized application
• You use a cloud platform when you want the services you present to your users to be an application as opposed to a website.

​

Final Thoughts And Exam Tips

• Know the difference between Heroku Connect and Salesforce Connect. Nailing this key concept will allow you to eliminate a ton of "bad" answers throughout the exam.
• Get familiar with the use of a follower Postgres DBs
• Understand the difference between available and installable add-ons in Private Spaces
• Study up on the terms that might be foreign. If this seems daunting, don't worry...I'll be publishing a Heroku Architecture dictionary in my next blog post!

​And as always with Salesforce exams, it's best to eliminate answers in order to identify the "right" one. Usually there are two answers that are just flat out wrong!