Software Development and Design¶

Exam topics covered:
1.1 Describe distributed applications related to the concepts of front-end, back-end, and load balancing

1.2 Evaluate an application design considering scalability and modularity

1.3 Evaluate an application design considering high-availability and resiliency (including on-premises, hybrid, and cloud)

1.4 Evaluate an application design considering latency and rate limiting

1.5 Evaluate an application design and implementation considering maintainability

1.6 Evaluate an application design and implementation considering observability

1.7 Diagnose problems with an application given logs related to an event

1.8 Evaluate choice of database types with respect to application requirements (such as relational, document, graph, columnar, and Time Series)

1.9 Explain architectural patterns (monolithic, services oriented, microservices, and event driven)

1.11 Explain the concepts of release packaging and dependency management

1.12 Construct a sequence diagram that includes API calls

Architectural Patterns¶

Monolithic¶

• An application which combines all components into a single program
• All software components of an application are assembled together and tightly packaged
• Lack of modularity means the application is difficult to scale, or to swap components
• Difficult to maintain and update because all code is in a single large program
• Longer software development cycles, typically with months or even years between releases
• Mainframe apps were designed using this approach

Service-Oriented¶

• Service-oriented architecture integrates distributed, separately maintained and deployed software components
• Each service represents a business activity
• Consumers of the services do not need to understand the service inner workings, therefore different services can be implemented using completely different programming languages
• Services run separately and communicate laterally across an Enterprise Service Bus (ESB), which is commonly implemented across an IP network
• A service presents a simple interface to the requester that abstracts away the underlying complexity. (ex. SOAP)
• Services components can be reused across applications (ex. sharing a database)
• built on the idea of "share-as-much-as-possible"

Microservices¶

• Structures an application as a collection of small services that are self-contained, each implementing a single business function
• Similar concept to Service Oriented, however with microservices the services are even more distributed into single-purpose services that do one thing really well
• Microservices communicate with each other using an API, typically a lightweight protocol such as HTTP/REST or AQMP
• Services are typically containerized using a container runtime such as Docker
• Easy to scale and/or swap components
• Common for each service to have its own data store. (Ex. Web front-end uses MySQL database, while Shopping Cart functionality uses MongoDB)
• New features can quickly and easily be implemented
• Short software development lifecycle, weeks, days or even hours
• built on the idea of "share-as-little-as-possible"

Event Driven¶

• Services are distributed into components that handle a specific event (ex. user submits an order). These events are propagated on a message queue where other services (Subscribers) can take some action based on the event
• Services communicate amongst each other using a messsage queue
• A broker (or mediator) serves as an aggregation point for other services
• Publishers are services that add messages to a message queue that the broker manages
• Subscribers process the messages that were put on the queue by the subscribers
• Queue is a first-in first-out (FIFO)
• Kafka and RabbitMQ are common message queue implementations

Scalability¶

Vertical Scaling¶

• Scale up
  • Make something bigger, such as increasing cpu/memory on a server
• Scale down
  • Making something smaller by reducing capacity. Ex. Decreasing the amount of memory allocated to a VM because it is not being used.

Horizontal Scaling¶

• Scale out
  • Increasing the number of instances of an application to meet an increase in demand
• Scale in
  • Decreasing the number of instances of an application, to release resources that are not being utilized

Modularity¶

• Provides the ability to change components of the application (ex. change the database)
• Monolithic applications are not modular at all, whereas Microservices are highly modularized

High Availability¶

• Measures responsiveness to a request
• Consider the ability of the application to recover from a failure of a single resource
• Fate sharing is the likelihood of a single component failure impacting the application (ex. all services running on the same physical machine)

Latency and Rate Limiting¶

Latency¶

• Delay incurred when a request is received
• The more distributed the application, the more likely that latency can become a problem
• Monoliths have very low latency, while microservices depend on the latency of the network they are communicating across

Rate Limiting¶

• Intentionally throttling requests in order to prevent overwhelming a service

Maintainability¶

• How easy/difficult is it to make a change to the application without breaking it, or being able to easily determine if a change broke the application by testing.

Characteristics of a Maintainable Application:

• Availability of tests, and automated testing
• Understandability. Code is properly indented, commented, and conforming to coding standards

Observability¶

• The ability to be able to explain what is happening inside the application by observing what is happening from outside the application
• Some examples of observability:
  • implementing a logging system with the ability to increase the verbosity of logging for troubleshooting
  • automated log generation and bundling for offline analysis
  • error condition reporting to external systems (email, etc.)
  • system health indicators that provide up/down status of a service

Databases¶

Relational¶

• Data stored in tables
• One field in each table must be designated as the Primary Key
• Commonly use SQL (Structured Query Language)

Document¶

• Could be a collection of JSON dictionaries
• Collection of dictionaries is a "book"
• Can easily add extra, optional fields
• Works well for catalogs, user profiles, and content management systems where each document is unique and evolves over time
• Great for eCommerce and/or blog/video sites
• MongoDB is a Document database

Graph¶

• Primarily concerned with relationships
• Consist of Nodes and Edges (a.k.a. relationships)
• Nodes carry individual record data
• Edges carry information about relationships between nodes
• Good for modeling inter-dependencies between data
• Social networking applications (Twitter, Facebook, etc.) would be a good candidate
• Also commonly used in fraud detection and recommendation engines (making product recommendations based on others who have similar purchase history)
• Neo4J and Cassandra are examples of graph databases

Columnar¶

• Uses tables to store data, but do so by column rather than row
• Data is read and written by column rather than row
• Optimized for fast retrieval of columns of data
• SQL is used to query
• Performs poorly with a small number of rows
• Adding new rows is slow since data in each column needs to be written individually
• Ideal for Data Warehousing and Big Data applications
• Druid is a column-oriented data store that is used widely today

Time Series¶

• Uses tables to store data
• Have a column with a timestamp for each event
• Typically work with monitoring and graphing applications
• InfluxDB is an example of a Time Series database
• Popular for IoT applications

Release Packaging and Dependency Management¶

Release packaging is how software is bundled up for delivery to end users. It is closely related with dependency management, which is the concept of bundling in any required packages that are needed for the software to operate. A good release packaging and dependency management strategy bundles in all required dependencies into a single package, or installer file. On Windows, this might be an .msi file, or a .rpm for Linux. The developer should identify all dependencies up front and bundle them into the installer package. Ideally the software testing process will include testing the installer on a clean system that has never had the application before. This will help to identify any dependencies that the developer may have had on their system that they failed to include in the installer package.

Python dependencies can be identified with pip using the pip freeze command. The output of that command can be saved as a text file and fed into the installer on another system using the pip install --requirement [filename] command. This will install all of the requirements as were captured by the pip freeze command.

API Sequence Diagrams¶

A Sequence Diagram is used to illustrate the process of how different application services communicate to perform an action. Consider an eCommerce site, when a user wants to purchase an item they put items in the cart and when ready they initiate the checkout process. The checkout process might involve several different services and/or systems such as credit card transaction processing, shipping, and others. A sequence diagram could be used to diagram the interactions between these various components. The sequence diagram will typically have the services listed across the top and/or bottom of the diagram, with arrows showing the communication between components. Below is an example sequence diagram.

The above example was taken from a site called Creately, which has a great tutorial and more examples here: https://creately.com/blog/diagrams/sequence-diagram-tutorial/