CHAPTER 7
Digitizing J&S Food's Business Model Using AWS—Implementing the VPC

The increasing presence of cloud computing and mobile smart phones is driving the digitization of everything across both consumer and enterprise domains. It is hard to imagine any area of human activity which is not being reengineered under this influence, either at present or in the very near future.

—Geoffrey Moore

The stake in this step of the digital transformation journey is to implement the technology in a cloud environment in a way that not only makes the operational and organizational models efficient but also allows J&S Food to deliver a superior digital food experience. The challenge is to achieve the intelligent and efficient use of technology with a laser focus on the processes and practices that enable the expected digital experience.

This chapter will show you how an AWS Solutions Architect leverages the Enterprise Cloud Migration (ECM) design pattern to speed the implementation of J&S Food's AWS computing environment.

In this chapter, you'll be part of an operational model digitization session involving an AWS Solutions Architect, application developers, testers, and IT operations.

The workshop will address issues such as developing an AWS migration strategy, defining an AWS cloud architecture, re-architecting applications for AWS, and migrating applications to AWS.

Transformation Journey's Third Stage: Digitizing the Business Model

The digitizing the business stage is about implementing cloud technology in a way that enables the expected digital food experience. It's a three-phase process including the implementation of the DevOps platform (Chapter 8, “Implementing J&S Food’s DevOps Platform Using AWS PaaS”), developing the innovation as a service platform (Chapter 9, “Developing J&S Food’s Innovation as a Service Platform Using AWS”), and this chapter, which is about implementing J&S Food's Amazon Virtual Private Cloud (VPC) that will not only host the company's virtual infrastructure resources but also support the company's digital business.

Figure 7.1 illustrates where the digital transformation team stands in the transformation journey.

Schematic illustration of the digitizing the business stage.

Figure 7.1: The digitizing the business stage

As Figure 7.1 indicates, the AWS Solutions Architect would tackle the digitization effort in these five steps:

  • Defining the AWS migration strategy
  • Sharing the digital business model
  • Defining the digital business application portfolio
  • Specifying the Amazon Virtual Private Cloud (VPC)
  • Executing the AWS migration strategy

Let's see how the AWS Solutions Architect would go about digitizing J&S Food's business model.

Defining J&S Food's AWS Migration Strategy

The problem with today's practice is that cloud migration strategy development is overlooked. Developing an AWS migration strategy is not a trivial task that can be improvised or narrowed down to a matter of taking applications to the cloud and making them compatible with the requirements of the AWS computing environment.

What you need to know is that, in the context of a digital transformation project, developing an AWS migration strategy is primarily about pinpointing the key processes of the digital business model, making sure that the applications underpinning these processes are migratable, and then proceeding with the technical adaptation and deployment of these applications to the AWS computing environment. As you can see, the perspectives and objectives are different.

Figure 7.2 illustrates the kind of AWS migration strategy development framework the AWS Solutions Architect would use.

Schematic illustration of J and S Food's AWS migration strategy.

Figure 7.2: J&S Food's AWS migration strategy

The AWS migration plan recommended in Figure 7.2 includes four steps:

  1. Sharing (with the implementation team) the digital business model
  2. Specifying the VPC architecture
  3. Developing the digital business applications portfolio
  4. Executing the AWS migration strategy

The next sections elaborate on each of them.

Sharing J&S Food's Digital Business Model

The AWS Solutions Architect would start the meeting by sharing the new digital business model with the implementation team (see Figure 7.3):

Schematic illustration of J and S Food's digital business model.

Figure 7.3: J&S Food's digital business model

The AWS Solutions Architect would then add the following:

Table 7.1 outlines the application list that would result as part of J&S Food's new digital business model.

Table 7.1: Concerned Business Domains and Related Applications

BUSINESS DOMAIN ACTIVITIES EXISTING APPLICATIONS NEW APPLICATIONS
Customer Insights PeopleSoft CRM Big data solutions based on Amazon Elastic Map Reduce (EMR)
Digital Product and Service Development No specific application or platform Digital product and service development platform based on DevOps
Digital Product and Service Launch No specific application or platform Digital product and service development platform based on DevOps
Social Media Marketing and Sales None Two-sided marketplace platform; ecommerce website; Hootsuite (a social media management platform)
Customer Value Increase None AI / ML solution based on Amazon SageMaker
Digital Business Management None Not applicable
Human Resource Management Not applicable Not applicable
Digital Technology Strategy Not applicable Not applicable
Procurement Not applicable Not applicable

Let's discuss the development of J&S Food's digital business application portfolio.

Defining the J&S Food's Digital Business Application Portfolio

This activity is about screening the applications identified in Table 7.1 that are migratable to the AWS computing environment. The application readiness for AWS is evaluated and the application migration strategy is determined accordingly.

Figure 7.4 explains the digital business application portfolio development process.

Each application in the application candidate list is evaluated against two main criteria: compatibility with the technical and technological requirements of AWS and the risks and constraints.

The application migration strategy refers to the adaptation of the application's code and architecture to the AWS computing environment requirements. It is determined based on the AWS 6R's model explained in Table 7.2.

Schematic illustration of the digital business application portfolio development process.

Figure 7.4: The digital business application portfolio development process

Table 7.2: The AWS 6R's Model

MIGRATION STRATEGY DESCRIPTION
Re-host Also referred to as lift-and-shift, this application migration approach is about moving the application in the AWS environment without changes.
Re-platform Also referred to as lift, tinker, and shift, this migration method is about making few optimizations to achieve tangible benefits.
Re-factor / Re-architect This migration approach is about re-architecting the application using AWS services and features to make it compatible with the AWS computing environment.
Re-purchase This approach is about dropping the licensing method in favor of the software-as-a-service (SaaS) model.
Retire This recommendation is about decommissioning the application if it's no longer needed.
Retain This recommendation is about postponing the application migration or keeping it in the organization's on-premises infrastructure.

Applying the screening criteria and deciding on the adequate application migration strategies, participants would determine that the ecommerce website and the future two-sided marketplace application are part of the J&S Food's digital business application portfolio.

The PeopleSoft CRM and SCM ERPs would not migrate to the J&S Food's AWS computing environment, and the ecommerce website would be re-factored to make it compatible with the AWS computing requirements.

Specifying J&S Food's Virtual Private Cloud Architecture

In this step, the AWS Solutions Architect would warn as follows:

The Solutions Architect would also reassure the audience as follows:

Understanding the Enterprise Cloud Migration Model For AWS

The enterprise cloud migration (ECM) architecture for AWS, as discussed in Chapter 4, “Industrializing Digital Product and Service Development,” is a cloud architecture design pattern developed by this book's author. The ECM design pattern seeks to simplify, facilitate, and speed the implementation of an enterprise cloud in the AWS environment.

This framework organizes the most commonly used AWS services into five key areas, forming what's known as the organization's virtual private cloud (VPC). It suggests a VPC architecture specification in three steps:

  • Deriving the organization's VPC architecture from the ECM design pattern diagram
  • Removing any useless AWS service and feature or adding any new AWS service and feature
  • Describing the purpose and role of each AWS service, component, and feature in the overall architecture

Let's pay attention to what the AWS Solutions Architect would say about J&S Food's next VPC.

J&S Food's Virtual Private Cloud Specified

The proposed J&S Food's AWS cloud architecture is projected on a screen, as represented in Figure 7.5.

The consultant would start by clarifying the following:

Schematic illustration of the J and S Food's VPC.

Figure 7.5: The J&S Food's VPC

As the diagram on the screen is fairly complex, the consultant would reassure the participants as follows:

The next sections elaborate on how the Solutions Architect would justify the architectural options.

The Availability Zone

The availability zone purpose and benefits cannot be understood without knowing what an AWS region is. AWS regions are separate geographic areas that AWS uses to house its infrastructure.

An availability zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS region. They provide inexpensive, low-latency network connectivity to other availability zones in the same AWS region. Each region is completely independent.

The Solutions Architect would explain as follows:

The Solutions Architect would further justify as follows:

In fact, the AWS availability zones are designed for physical redundancy and provide resilience, allowing for uninterrupted performance, even in the event of power outages, Internet downtime, floods, and other natural disasters.

Amazon CloudFront and the Content Delivery Network

Then the Solutions Architect would proceed with Amazon CloudFront,

Understand Amazon CloudFront as a worldwide network of data centers called edge locations. The goal is to securely deliver to your customers data, videos, applications, and APIs at the lowest possible latency.”

Being specific, the Solutions Architect would add,

We'll need to create a CloudFront distribution, a content delivery network (CDN), to reduce the volume of application origin (location where content is stored) requests. It causes content to be stored in CloudFront edges and regional caches and fetched only when needed. That's how low latency is obtained.”

J&S Food’s Virtual Private Cloud

The AWS Solutions Architect would tell participants to think of the VPC as follows:

The Solutions Architect would further clarify as follows:

Let's review what the Solutions Architect would say about how these six elements contribute to J&S Food's AWS cloud architecture.

The Internet Gateway, Route Tables, and Network Access Control List

The Solutions Architect would ask participants to imagine the Internet gateway as a component that connects the VPC to the Internet and to other AWS virtual infrastructure resources and services.

He would certainly make clear how the Internet gateway works:

From the perspective of the Internet gateway's role in J&S Food's AWS cloud, the primary purpose of route tables will be to control and enable outgoing network traffic, more specifically, the traffic from J&S Food's virtual infrastructure to the Internet.

The Solutions Architect would certainly remind the participants about the following:

Route tables contain the information needed to forward traffic along the best path toward its destination. The destination includes either the Internet or other virtual infrastructure resources within J&S Food's AWS cloud.

As to network ACLs, like route tables, their role is to secure network traffic within J&S Food's AWS cloud. Participants might ask the following:

Be aware that network ACLs provide additional security levels, unlike route tables that are focused solely on outgoing traffic, network ACLs are concerned about inbound and outbound traffic.

The Public Subnet Structure Elements

The public subnet is one that's associated with a route table that has a route to an Internet gateway.

The Solutions Architect would explain the public subnet as follows:

J&S Food's VPC will build on public subnets to allow direct access to the two-sided marketplace platform.

What you need to know is that, in addition to IP address ranges assigned to the AWS resources under their control, public subnets are associated with a network address translation (NAT) gateway.

NAT gateways enable instances, or any other AWS virtual infrastructure resources in a private subnet, to connect to the Internet or to other AWS services. They prevent the Internet from initiating connections with those instances and resources.

The Private Subnet Structure Elements

Unlike public subnets, private subnets route traffic through a NAT gateway in the public subnet. The NAT gateway forwards traffic to the Internet gateway.

The Solutions Architect would state the following:

The Site-to-Site VPN Connection

A virtual private network (VPN) connection refers to the connection between your VPC and your own on-premises network. Site-to-site VPN supports Internet Protocol Security (IPsec) VPN connections.

Your AWS site-to-site VPN is a permanent connection designed to function as an encrypted link between your AWS cloud and remote sites.

In J&S Food's AWS cloud, the site-to-site VPN connection will enable secure communications between the AWS resources in the VPC with your on-premises infrastructure.

J&S Food’s Extended Elastic Compute Cloud Building Block

The extended EC2 is a construct representing the idea of a virtual application server in the AWS computing environment.

By analogy, a virtual application server is a type of server designed to install, operate, and host applications and associated services in the most effective and efficient way possible.

The goal is to bundle the many and scattered AWS resources involved in efficiently hosting and running applications into a single, logical concept that facilitates not only understanding but also the architectural design effort.

The extended EC2's intent is to host and run the application supporting J&S Food's two-sided marketplace platform. Figure 7.6 shows the AWS services and features that comprise the extended EC2.

The following sections elaborate on what the AWS Solutions Architect would say about the features of the extended EC2.

Schematic illustration of an overview of J and S Food's extended EC2.

Figure 7.6: Overview of J&S Food's extended EC2

Instance Type

The concept of instance type is the hardware configuration underpinning the EC2 instance. The AWS Solutions Architect would propose to use the T2.2Xlarge instance type, which is appropriate for applications with large resource requirements. Table 7.3 describes a T2.2Xlarge instance type.

Table 7.3: The Characteristics of T2.2Xlarge Instance Type

CHARACTERISTIC VALUE DESCRIPTION
vCPUs 8 AWS instances support multithreading, which enables multiple threads (a thread is simply a process) to run in a single CPU. Each virtual central processing unit (vCPU) is a thread of a CPU core.
RAM (GiB) 32 Random access memory (RAM) is the memory capacity of the EC2 instance. The larger the RAM, the faster the processing.
CPU Credits/hr 81 CPU credits allow T2 instances to have CPU performance beyond the baseline performance provided by the EC2. One CPU credit is equal to one minute of a full CPU core.

To the question why not any other instance type, the Solutions Architect would advocate his choice:

Amazon Machine Image

The role of the Amazon Machine Image (AMI) is the software configuration of the instance intended to support the two-sided marketplace platform. The AWS Solutions Architect would propose to use the WebSphere Liberty AMI, as described in Table 7.4.

Table 7.4: Features of the AMI Supporting WebSphere Liberty

FEATURES DESCRIPTION
AMI type 64-bit (x86) Amazon Machine Image
Operating system (OS) Linux/Unix, Ubuntu
Other software WebSphere Liberty

Anticipating the question, “Why continue with IBM WebSphere?” the AWS Solutions Architect would reply as follows:

The AWS Solutions Architect would conclude as follows:

Key Pair

By default, AWS requires what's known as a key pair, which consists of a private and a public key. A key pair is a set of security credentials that will be used to prove your organization's user identities when connecting to an instance. Amazon EC2 will store the public key, and your organization will store the private one. The key pair mechanism eliminates the hassle of using a password to access the EC2 instances securely.

IP Addresses

By default, the EC2 instance supporting the two-sided marketplace will be assigned a public IP address. The IP address is automatically picked from the IP address range associated with the public subnet controlling the instance.

Elastic Block Store–Backed Instance

The instance hosting the two-sided marketplace application will be an Elastic Block Store (EBS)–backed instance that offers easy backup and restore solutions. As discussed in Chapter 1, “The Digital Economy’s Challenges, Opportunities, and Relevance of AWS,” EBS provides raw block-level storage, and it supports uses such as formatting devices with a filesystem. An EBS-backed instance means that the root volume is an EBS volume, and storage is persistent. EBS-backed instances can be stopped without losing data.

The AWS Solutions Architect would promote the architectural choice as follows:

Containers

The AWS Solutions Architect would argue the importance of containers as follows:

The AWS Solutions Architect would justify the architectural option as follows:

Drawing participants' attention, the AWS Solutions Architect would add the following:

Lambda Functions

As to serverless, the AWS Solutions Architect would explain the following:

The AWS Solutions Architect would further clarify as follows:

To conclude, the AWS Solutions Architect says the following:

J&S Food’s Extended Storage Build Block

The storage building block specifies the storage solutions that will be used in J&S Food's AWS cloud. While Simple Storage Service (S3) will not be a key component of the application storage infrastructure, Relational Database Service (RDS) and Elastic MapReduce (EMR) will be the hub of J&S Food's storage capability.

Relational Database Service Instances

In addition to providing the services needed to store, update, and retrieve the two-sided market application's data, the RDS instance offers managed database management tasks, such as migration, backup, recovery, and patching.

To avoid useless and expensive changes, Oracle is selected as the relational database management system (RDBMS).

The AWS Solutions Architect would advise as follows:

The AWS Solutions Architect would add the following:

Elastic MapReduce (EMR)

The Elastic MapReduce (EMR) platform will support J&S Food's data analytics activities. The AWS Solutions Architect might say the following:

The consultant would the explain a number of precautions that would be taken:

J&S Food’s Extended Fault Tolerance Building Block4

The purpose of J&S Food's AWS platform's fault tolerance services is to ensure high availability for the two-sided marketplace application. These services include Elastic Load Balancing (ELB) and Route 53. Let's discuss their role.

Elastic Load Balancer

ELB allows for the monitoring of the health of the two-sided marketplace application and its performance in real time based on CloudWatch metrics, logging, and request tracing.

To offer a highly available application and deliver the expected superior digital food experience, three best practices would apply. These include app-tier ELBs health check, ELB access log, and ELB cross-zone load balancing enabled.

App-tier ELBs health check is the mechanism that determines the availability of registered EC2 instances and their readiness to receive traffic. Any downstream server that does not return a healthy status is considered unavailable and will not have any traffic routed to it.

ELB access log is the system that ensures that your AWS elastic load balancers use access logging to analyze traffic patterns and identify and troubleshoot security issues.

ELB cross-zone load balancing enabled is an option that ensures high availability for your ELBs by using cross-zone load balancing with multiple subnets in different AZs. Cross-zone load balancing is the idea that each load balancer distributes traffic across registered EC2 instances in all enabled availability zones.

Route 53

Amazon Route 53 will help to connect the requests of online customers to the infrastructure running in J&S Food's AWS cloud. It will help to configure DNS health check to route traffic to a healthy endpoint. Moreover, it offers the ability to individually monitor the health of the two-sided marketplace application and its endpoints. What you need to know is that Amazon Route 53 is a cloud Domain Name System (DNS) web service that connects user requests to infrastructure running in the AWS computing environment.

J&S Food’s Extended Security Build Block

The purpose of J&S Food's security services is to secure the access to the two-sided marketplace platform and secure the network traffic within the company's AWS cloud. These services would include identity and access management (IAM) and encryption services. Let's discuss them now.

Identity and Access Management

AWS Identity and Access Management (IAM) will help to securely control access to the two-sided marketplace platform and underpinning virtual infrastructure resources. IAM will be used to control authenticated (signed in) and authorized (has permissions) online customers.

The Solutions Architect would clarify this as follows:

To finish with identity and access management, the Solutions Architect would add the following:

Security Groups

A security group will be used to act as a virtual firewall for the EC2 instance hosting the two-sided marketplace application. The goal is to control incoming and outgoing traffic. Inbound rules of the security group control the incoming traffic to the EC2 instance, and outbound rules control the outgoing traffic from the instance.

Key Management Service

J&S Food's security services will build on AWS Key Management Service (KMS) to create and control encryption keys used to encrypt data. KMS uses envelope encryption in which data is encrypted using a data key that is then encrypted using a master key.

Executing J&S Food's AWS Migration Strategy

This activity in the AWS migration plan is where the actual application migration work takes place. The goal is to adapt the applications selected as part of the two-sided marketplace platform to the requirements of the AWS computing environment.

The Solutions Architect would focus on an iterative process underpinning the technical migration effort. This process is known as the migration factory process.

Understanding the AWS Application Migration Process

The Solutions Architect would warn the participants as follows:

The factory model is the circular part of the migration plan, as illustrated in Figure 7.2. It is the application of the industrialization principles defined in Chapter 4. These principles seek to accelerate the migration process and guarantee that applications fully adhere to the requirements of the AWS computing environment.

In a migration factory approach, applications move through what looks like an assembly line of five steps including discover, design, build, validate, and cutover. Let's briefly discuss these steps before applying them to the migration of J&S Food's ecommerce website.

Discover

This step is where the application's current architecture is pieced together and assessed versus the requirements of the selected migration strategy. Application development stakeholders including developers, testers, and technical architects are involved in discussions around the following questions:

  • What are the current hardware features including CPU, RAM, storage capacity, and network interfaces?
  • What is the current software configuration including operating system (OS), database, and ERPs?

Design

In this step, the application is redesigned according to its related migration strategy. The goal is to make sure that the application will enable the expected digital business experience.

Build

This step is where the new functions and architectural changes are implemented. The goal is to make sure that the application will run as expected in the AWS computing environment and that it effectively contributes to the desired digital business experience.

The activities carried out by the application development stakeholders include the following:

  • Provisioning the target computing environment
  • Deploying the application to the target computing environment
  • Implementing the architectural changes
  • Performing unit tests to assess the application readiness for the validate step

Integrate

In this step, the development stakeholders implement the application's external connections. The goal is to implement the mechanisms to ensure that the application can efficiently and safely communicate with your organization's on-premises infrastructure or with other external cloud platforms.

The activities carried out by application development stakeholders include the following:

  • Configuring the site-to-site VPN connections
  • Establishing the dedicated network connections between your AWS environment and your on-premises infrastructure using AWS direct connect
  • Setting up hybrid cloud environments using VMware cloud on AWS (VMC)

Validate

In the validate step, the application undergoes a series of tests including build verification, functional, performance, disaster recovery, and business continuity tests. The goal is to make sure that it's compatible with the AWS computing environment requirements and that they can contribute to the expected digital business experience.

Cutover

In the cutover step, the AWS migration team executes the cutover plan that was agreed upon with the application owners. Performance user acceptance test (UAT) and operational acceptance tests (OAT) are performed at this stage to ensure a successful cutover.

The next sections illustrate the AWS migration factory process as the Solutions Architect would apply it to migrate J&S Food's ecommerce website and extend it into a two-sided marketplace platform.

Migrating J&S Food's Ecommerce Website Into a Two-Sided Marketplace Platform

The AWS consultant would present the objective as follows:

The consultant would further clarify as follows:

Then the consultant would write the workshop's agenda on the whiteboard as follows:

Starting with the implementation of J&S Food's VPC, let's see how the Solutions Architect would migrate the ecommerce website to the AWS computing environment.

Implementing J&S Food’s Virtual Private Cloud

As Figure 7.7 shows, the VPC creation process leverages AWS CloudFormation designer and infrastructure as code techniques to speed the implementation of the company's AWS computing environment.

The Solutions Architect would explain the implementation of the VPC architecture as follows:

Schematic illustration of implementation of J and S Food's VPC architecture using AWS CloudFormation Designer.

Figure 7.7: Implementation of J&S Food's VPC architecture using AWS CloudFormation Designer

What you should bear in mind is that the combined use of the enterprise cloud migration (ECM) design pattern and AWS CloudFormation designer reduces the implementation time, not in days but in weeks.

Discovering the Ecommerce Website Three-Tier Architecture

The Solutions Architect would draw the participants' attention as follows:

In this step of the factory model, the goal is to understand the application's architecture as well as the source code. Figure 7.8 provides an overview of J&S Food's application architecture.

Schematic illustration of J and S Food's ecommerce website's as-is architecture.

Figure 7.8: J&S Food's ecommerce website's as-is architecture

The application is based on a three-tier application including a presentation server, a business logic server, and a legacy data server.

The AWS Solutions Architect praises the application's architecture:

Let's discuss these architectural components.

The Presentation Server

The presentation tier is the visible part of the application. The role of the presentation server is to display information related to services such as browsing merchandise, purchasing, and shopping cart contents. The presentation layer communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network.

The presentation server is based on Jakarta Server Pages (JSP), formerly Java Server Pages. JSP is a collection of technologies that provide the mechanisms needed to create dynamically generated web pages based on HTML, XML, and SOAP. JSP enables developers to mix up static HTML with dynamically generated content of servlets.

The Business Logic Server

The Business Logic Server is responsible for performing business functions such as online order capture and order fulfillment. The business functions are primarily based on Java server. Servlets are Java programs that run inside a Java-capable HTTP server.

Dynamic JSP pages can invoke a servlet implementing these business functions by issuing a specific URL from the browser (HTTP client). Servlets are used to handle the request obtained from the dynamic JSP page via the web server, process the request by invoking the PeopleSoft function via an API, produce the data obtained in response, and then send the response back to the JSP page via the web server.

The Legacy Data Server

Legacy data is essential enterprise information that is stored in a computer system. J&S Food relies on PeopleSoft ERPs to store, update, and retrieve legacy data.

Extending the Ecommerce Website Architecture to a Two-Sided Marketplace Platform

As in the discover phase, the Solutions Architect would remind the participants the following:

Figure 7.9 represents the architecture of J&S Food's digital business platform in the AWS cloud. This architecture resulted from the discussions involving the AWS Solutions Architect, the enterprise architect, your developers, and IT operations.

Schematic illustration of an overview of J and S Food's two-sided marketplace platform.

Figure 7.9: Overview of J&S Food's two-sided marketplace platform

The AWS version of J&S Food's digital business platform is composed of four components including the presentation server, the business logic server, the AWS Simple Notification Service (SNS), and the two-sided marketplace application. Let's discuss them now.

The Presentation Server

As in the J&S Food's on-premises environment, the digital business platform would be based on a three-tier architecture. The presentation server is the first tier. Its scope covers hosting the web pages of the digital business platform, showing the online customers the web pages needed to either input or read information about orders, food, delivery persons, and customers.

The presentation server builds on JSP pages to invoke servlets in the business logic server to either input or get orders, food product, and delivery people's information.

The Business Logic Server

The second tier of the digital business platform architecture is business logic server. In addition to interacting with the PeopleSoft module in the on-premises environment via APIs built on a VPN connection to get or update data, the business logic server's scope covers various functions including capture orders, show orders, and trigger delivery persons searches.

A key piece of information to know is that the interactions between the digital business logic server and the two-sided marketplace application are supported by an Amazon SNS platform. The business functions build on servlets to invoke APIs that allow them to interact with PeopleSoft ERP to either get or update information about orders, customers, food products, and delivery persons.

The AWS Simple Notification Service

The Amazon Simple Notification Service (SNS) is a managed publish/subscribe (also known as pub/sub) service. The key thing to know is that this system enables communication between systems that are not directly connected. One side publishes messages to a shared communication channel, called a topic, and the other side subscribes to the messages from this topic.

The digital business logic application and the listener component of the two-sided marketplace application are subscribers to three topics, as described in Table 7.5.

Table 7.5: The J&S SNS Topics and Messages

TOPICS MESSAGES SENDER, RECEIVER, ACTION
Delivery person Delivery person requested Sent by the digital business logic application to the listener of the two-sided marketplace application. The listener triggers the geolocate function to dispatch the “delivery person requested” message.
Order Order fulfilled Order fulfilled message is sent by the listener to the digital business logic server. The digital business logic server updates the order information stored in the PeopleSoft CRM system.
Tracking Order tracking requested The order tracking requested message is sent by the listener to the digital business logic server. The digital business logic server retrieves order tracking information and sends it back to the listener. The listener orchestrates the display of the order tracking information to the customer mobile devices.
The Two-Sided Marketplace Application

The primary purpose of the two-sided marketplace application is to connect online customers with delivery persons. To achieve that goal, the application builds on four fundamental functions including listener, geolocate, dispatch request, and track delivery.

The listener function listens to requests that the online customer sends via a laptop or mobile device and triggers one of these functions: geolocate, dispatch request, and track delivery.

The listener interacts with the business logic server of the ecommerce website and with the two-sided platform via an AWS Simple Notification Service (SNS) message queue to capture online customer requests and accordingly trigger the two-sided marketplace platform's functions.

The listener builds on Amazon SNS to receive and send messages back and forth.

Amazon SNS, as illustrated in Figure 7.10, is a managed service that provides message delivery services from publishers to subscribers (also known as producers and consumers).

Schematic illustration of amazon SNS.

Figure 7.10: Amazon SNS

Source: Amazon

Publishers communicate asynchronously with subscribers by sending messages to a topic that consumers subscribe to prior to getting messages.

SNS is a logical access point and communication channel that supports various purposes including sending and receiving short message service (SMS), email, and HTTP/S requests, as well as invoking serverless functions via the AWS Lambda service.

The geolocate function builds on location technologies such as GPS or IP addresses to identify and track the whereabouts of connected electronic devices. The core objective of the geolocate function is to connect online customers and delivery persons in an effort to get online orders delivered.

The geolocate function interacts with the listener to capture messages published and associated with the topic “delivery person's geolocation” and then build on Lambda API to invoke the lambda serverless function Geolocate.

The dispatch request function's purpose is to dispatch an SMS to J&S Food's delivery network.

The dispatch request function interacts with the listener to capture messages associated with the topic “delivery person requested.” It then builds on the Lambda API to invoke the Lambda serverless function delivery person.

The track delivery function's goal is to provide the online customers with tracking order information.

The track delivery function interacts with the listener to capture messages published and associated with the topic “delivery persons” and then build on the Lambda API to invoke the lambda serverless function Delivery Person.

J&S Food's Digital Business Microservices: Reusable Modules

Serverless functions are encapsulated in containers to form J&S Food's microservices. They include Geolocate and Delivery Person. Figure 7.11 illustrates their data and functions.

Schematic illustration of J and S Food's digital business microservices.

Figure 7.11: J&S Food's digital business microservices

The microservices logical representation is based on the Unified Modeling Language (UML) class diagram formalism. The class diagram highlights the serverless functions to implement and the data that they handle.

The microservice encapsulated in the geolocate container handles three primary data and functions, as outlined in Table 7.6.

Table 7.6: Data and Functions of the Microservice Geolocate

DATA AND FUNCTIONS DESCRIPTION
Device coordinates Refers to the electronic device's position expressed in latitude and longitude coordinates.
Geographic location Refers to the geographic location associated with device coordinates.
Location source The source that provides the device coordinates and geographic location. This could be satellite, Wi-Fi, and mobile network.
LocateCustomer() This function locates the geographic area and full address of the online customer.
LocateDeliveryMan() Based on the geographic area and address of the customer, this function locates delivery people geographically closest to the online customer.
SendSMS() This function issues an SMS to the delivery person geographically closest to the online customer. These SMSes notifies the need for a delivery person at a specific area.

The microservice encapsulated in the Delivery Person container handles three primary pieces of data using three functions, as described in Table 7.7.

Table 7.7: Data and Functions of the Delivery Person Microservice

DATA AND FUNCTIONS DESCRIPTION
Delivery Person Identity Refers to the delivery person information including full name, address, and taxpayer identification number (TIN).
Mobile Number Delivery person mobile number.
IP Address Delivery person mobile's IP address.
DispatchRequest() This function issues an SMS to the delivery persons geographically closest to the online customer. These SMSes notifies the need for a delivery person at a specific area.
TrackDelivery() Based on online order identification provided as input, this function returns the order tracking information.

Implementing J&S Food’s Two-Sided Marketplace Platform

This is the build step of the AWS migration factory process. The bottom line for the development team is to migrate the existing ecommerce website to J&S Food's AWS computing environment and adapt it to the technical and technological requirements.

Migrating J&S Food's Existing Ecommerce Website to the AWS Computing Environment

Before starting the implementation, the Solutions Architect would recommend migrating the existing ecommerce website to the EC2 instance of J&S Food's virtual private cloud VPC (see Figure 7.6). The process will be based on the AWS Elastic Beanstalk service.

AWS Elastic Beanstalk is an easy-to-use service for deploying and scaling web applications and services developed with Java, .NET, PHP, Node.js, Python, Ruby, and Go. Figure 7.12 illustrates the application migration process using AWS Elastic Beanstalk.

Schematic illustration of an overview of the application migration process with AWS Elastic Beanstalk.

Figure 7.12: Overview of the application migration process with AWS Elastic Beanstalk

The developer simply uploads the application's code, and Elastic Beanstalk automatically handles the deployment, from capacity provisioning, load balancing, and auto-scaling to application health monitoring.

Overview of the AWS Modern Application Development Framework

To ensure the delivery of an application that meets the requirements and challenges of J&S Food's digital food experience, the Solutions Architect would recommend an ingenious approach inspired from AWS modern application development principles, as illustrated in Figure 7.13.

Schematic illustration of the modern application development on AWS framework.

Figure 7.13: The modern application development on AWS framework

The framework builds on three pillars to facilitate the rapid development of secure, resilient, elastic, modular, and fit-for-purpose applications in the AWS computing environment. The following sections discuss the framework's elements and how it would help to deliver the two-sided marketplace software.

The Digital Business Architecture Element

The importance of the digital business architecture in the development of software is that the diagrams and architecture blueprints it provides highlight the software's goal in terms of functions to implement and interactions between these functions, as well as the data that they handle.

With the goal, functions, and data in sight, the software architecture, AWS computing environment, and operational requirements to deal with, as well as the development team's productivity, are ready to be discussed to elaborate a software development strategy.

The Solutions Architect would explain the next steps as follows:

Translation Rules: From the Business Architecture to the Software Architecture and the Software Development Strategy

The AWS modern application development framework is a set of key areas of concern that help to determine not only the software architecture but also its development strategy.

These areas of concern include architectural patterns, computing in modern application: containers and serverless, data management, developer agility, and the operational model. Let's discuss their role and importance.

  • Architectural Patterns  These are architectural principles that will help determine the best possible architecture for the software that will help to determine the best possible architecture for the software. Examples of such software architectural patterns include n-tier, event-driven, and microservices.

    As illustrated in Figure 7.12, participants would agree that the best architecture for the two-sided marketplace platform is a combination of n-tier, event-driven, and microservices approaches.

  • Computing in Modern Application—Containers and Serverless  This concern encourages developers to take advantage of containers and serverless to make applications more modular and increase their portability. As Figure 7.12 shows, J&S Food's software development stakeholders would agree that basing the two-sided marketplace platform on containers and serverless would make its development and maintenance easier.
  • Data Management   This concern emphasizes the need for the application to rely on the right datastore (SQL or NoSQL) but, more importantly, to decouple the application from its database by having them housed in separate microservices. The participants’ recommendation was to keep legacy Oracle database in J&S Food's on-premises environment and give access to it via a site-to-site VPN connection APIs.
  • Developer Agility   This concern stresses the need to provide the development team with the mechanisms for high productivity. These mechanisms include tool, infrastructure, methodologies, and work organization. The participants cited application code generators like AWS Amplify, continuous testing tools, Scrum agile, and Extreme Programming (XP) methodologies, as well as the UML object approach and serverless/AWS Lambda, as the factors likely to increase their productivity.
  • Operational Model   In this concern, the emphasis is placed on making the operational model ever more effective, efficient, and fast. Participants would praise mechanisms such as microservices, containers, serverless, and even tools like serverless/AWS Lambda, AWS Amplify, AWS Elastic Beanstalk and CodeDeploy as essential catalysts of the operational model performances.
The Resulting Software Architecture and Development Strategy Element

Discussions about the implementation of the two-sided marketplace software, based on the principles of AWS modern application development, would result in the architecture and development strategy summed up in Table 7.8.

Table 7.8: Two-Sided Marketplace Software Module Architecture and Development Strategies

MODULES DESIGN PATTERN AWS API DEVELOPMENT STRATEGY ELEMENTS
Listener Event-driven Simple Notification Service (SNS) Code generator, continuous testing platform, and XP methodology
App Logic Server Module N-tier SNS, Lambda, Elastic Container Service (ECS) Same as above
Digital Business Reusable Modules Microservices Same as above Same as above

Validating the Two-Sided Marketplace Platform

Validating is the last step in the migration of the application before its deployment in the experimentation phase. It's about performing a series of tests including build verification, functional, performance, disaster recovery, and business continuity tests. Table 7.9 summarizes the validation tests that the two-sided marketplace application will pass.

Table 7.9: The Two-Sided Marketplace Validation Tests

VALIDATION TESTS PURPOSE AND EXPECTED RESULTS
Build verification This is a set of tests run on the application build in the AWS computing environment to verify that the build is testable before it is released to a test team for further testing.
Functional This is a testing of the two-sided marketplace software that validates the application against the functional requirements/specifications.
Performance This is a testing process used for testing the two-sided application's speed, response time, stability, reliability, scalability, and resource usage under a particular workload.
Disaster recovery The disaster recovery test (DR test) examines each step in the two-sided marketplace application's disaster recovery plan as outlined in an organization's business continuity/disaster recovery (BCDR) planning process.
Business continuity tests This test verifies how effective the business continuity plan is in real-time scenarios. The bottom line is to look for weaknesses or gaps in the plan. Once weaknesses are identified, the teams can work together to improve them.

Key Takeaways

Digitizing a business model is not a simple matter that would consist in deploying applications. It's a complex job that can be long and risky and that requires both a solid understanding of the business model and the technology.

In this chapter, you learned about the benefits and value of a number of AWS migration tools that guided and facilitated the cloud migration process. These tools included the following:

  • The AWS migration strategy framework that provided an actionable migration plan that helped save precious time.
  • The digital business application portfolio development process that helped to rapidly identify the applications migratable to AWS.
  • The VPC blueprint that proves to be a powerful tool not only for specifying the company's AWS cloud architecture but also for implementing it using AWS infrastructure as code tools like CloudFormation designer.
  • The AWS Modern Application development framework, which offers software engineering mechanisms that help to quickly determine the software architecture of the applications to migrate to AWS.

In the next chapter, you'll be involved in the second phase of J&S Food's digital business model digitalization. This second phase is focused on the implementation of the DevOps platform that supports the development of digital products.

References

  1. 1.  Amazon Web Services, “AWS Cloud Adoption Framework (AWS CAF),” Amazon Web Services (2021). https://docs.aws.amazon.com/whitepapers/latest/aws-migration-whitepaper/the-aws-cloud-adoption-framework-aws-caf.html
  2. 2.  Amazon Web Services, “Introducing AWS CloudEndure Migration Factory Solutions,” Amazon Web Services (June 03, 2020). https://aws.amazon.com/about-aws/whats-new/2020/06/introducing-aws-cloudendure-migration-factory-solution/
  3. 3.  Amazon Web Services, “The 6 R's: 6 Application Migration Strategies,” Amazon Web Services (2021). https://docs.aws.amazon.com/whitepapers/latest/aws-migration-whitepaper/the-6-rs-6-application-migration-strategies.html