Cloud ArchitectureDavid “Mac” McDanielSr. Solution & Cloud Architectdmcdaniel@microstarkegs.comLinkedIn: https://www.linkedin.com/in/davidbmcdanielTwitter: CloudKegGuyTwitter list: https://twitter.com/CloudKegGuy/lists/aws

Mic

roSt

ar

His

tory 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 ofgasoline that didn’t get used!

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.

Numerous fixes but not capable of current needs.

Follow-Up from last monthSomebody 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

Source: http://stephendnicholas.com/archives/1217

This month’s focus: Cloud StrategyThis 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.

High Level StrategiesYou 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.

Capacity/Cost vs. Utilization

Goals of StrategyBefore 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.

Resulting StrategiesClearly document your chosen Strategies.

Also consider multiple Strategies for the same app. I.e., Phase 1 is lift-and-shift, Phase 2 is Redevelop.

ExampleMy 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

Pay-per-use compute

Highly reliable

Distributed

Topics for Next Meeting: ?

December 14

Would somebody like to present?

Additional topics?

More details or training oriented? Workshop?