This document discusses cloud architecture and strategies for migrating applications to the cloud. It provides background on the company MicroStar and its keg management applications. It then discusses different cloud migration strategies such as migration, redeployment, and redevelopment. It emphasizes evaluating goals like costs, security, and reasons for migrating when choosing a strategy. MicroStar's example is provided where its Great Plains application was migrated to AWS EC2 for scalability, reliability, and availability while its TAP application is being migrated to serverless AWS services for scalability and instant scalability. The document concludes by soliciting topics for the next meeting.

1. Cloud Architecture
David “Mac” McDaniel
Sr. Solution & Cloud Architect
dmcdaniel@microstarkegs.com
LinkedIn: https://www.linkedin.com/in/davidbmcdaniel
Twitter: CloudKegGuy
Twitter list: https://twitter.com/CloudKegGuy/lists/aws

2. MicroStar
History
Founded in 1996, MicroStar started with a simple idea: helping
leading brewers collaborate. Over time and in partnership with
the brewing community, MicroStar has evolved into the largest
diversified keg solutions company. We offer keg management
solutions leveraging our pool of more than 2.5 million kegs, keg
repair and maintenance services through our MicroStar Quality
Services division, and new and used keg sales and keg leasing
options through our new Kegcraft Division. Last year alone, we
prevented 3.3 million KG of carbon from entering the
atmosphere. That’s 372,500 gallons of
gasoline that didn’t get used!

3. Technology History
“TAP” application - used to manage/track shipments to and from Brewers and
Distributors (and warehouses and maintenance facilities).
Integrates billable transactions into Great Plains/Dynamics for posting and
invoice generation.
Written in VBScript and SQL Server over the past ~10 years by outside resource
who suddenly bailed on supporting the product.
“Single User” viewpoint of implementation.
No transaction support.
Moved from “basement” servers to AWS EC2 Cloud in 2015.

4. Follow-Up from last month
Somebody had mentioned to me that they were using raw TCP for their IoT
communications because their device was battery operated. I ran across this
comparison of MQTT to HTTPS:
93x faster throughput over HTTPS
11.89x less battery to send
170.9x less battery to receive
50% less power to keep connected
8x less network overhead

5. This month’s focus: Cloud Strategy
This month, I’ll be talking about creating a Cloud Strategy for your company, department or even project.
Many people think of different strategies correlated by company size, but I disagree. I believe you should
categorize by type of application that needs to be migrated. You could have more than one category
associated with your company.
I prefer to delineate general strategies by “use cases”. These use cases will determine what categories
you fall into. The primary use case is Applications. Other important use cases are Data Storage
(databases), document storage and backup or DR storage or environments.
The Applications use cases can comprise COTS (Commercial, Off-The-Shelf) applications, such as Great
Plains, SAP, Oracle Financials, Epic or more specifically, applications that use either “Fat Client” or
“executable” programs as a prime Actor. Another option are programs that are web-based, but run on
your servers (i.e., NOT SaaS). The last is any “home grown”/custom application(s) - where you have the
source code and can modify it.

6. High Level Strategies
You will find that there are only a few high level strategies.
1. Migration - moving the application (more-or-less) as-is.
a. Has many benefits - HA, DR, DevOps, Scalability (potentially), etc
b. Lowers costs the least*
2. Redeployment - Taking an application and deploying it (mostly) as-is, but
on a different platform.
a. Only able if using scripting language, Java or JavaScript or similar
3. Redevelopment - A luxury if you have the source, the time and the money.
a. Can create the most cost savings.

7. Capacity/Cost vs. Utilization

8. Goals of Strategy
Before choosing a strategy, you should identify your overall goals:
Costs - what is your budget? How will the dynamic scalability impact cost?
How will it also enable TTM & Innovation?
Security - Personally, I’d rather have AWS’ many security engineers preventing
DDoS and other attacks (see last week’s attack).
Why are you migrating? Costs? Scalability? High Availability? Performance?
Understand your reasons for migrating!
Advice: Don’t go in with an absolute strict budget.

9. Resulting Strategies
Clearly document your chosen Strategies.
Also consider multiple Strategies for the same app. I.e., Phase 1 is lift-and-shift,
Phase 2 is Redevelop.

10. Example
My company is a perfect example of multiple cloud strategies, actually. We use Great Plains from Microsoft and a custom,
home-grown application called TAP, which is written in VBScript.
Migrated GP DB and Terminal Server to EC2 - Why?
Scalability: Change change server size in minutes
Reliability: Massive redundant power, cooling and pipe
Security: Many security resources vs. 1
Availability: Can access from anywhere without VPN; can restore from scratch in a few hours
Migrating TAP to Lambda, API Gateway, RDS, WAF, SNS/SQS/SES, S3, IAM, Cognito - Why?
Virtually serverless
Instant scalability

11. Topics for
Next
Meeting: ?
December 14
Would somebody like to present?
Additional topics?
More details or training oriented? Workshop?