Leave a comment Posted on Technology

/Cloud

PalmSpringsCACropped

San Jacinto Peak, Palm Springs, California, May 2017

Cloud is not for everybody.
There are still some people who might say that and I might actually agree, but only at an application level with a short term view.  There are lot of parameters that need to be reviewed before a decision is made to move to cloud.
But at an enterprise level, my response would be – “you got to be kidding me!”

As internet has become more and more ‘utilatarian’, the compute / storage facilities are going to be so as well. Very soon it would be as archaic as a company planning to generate its own power / electricity.

Next turn: /Will it fly?

Leave a comment Posted on Technology

/How to scale

National Arches

Arches National Park, Utah, Mar 2017

Lets say our current application is hosted on 2 2XL servers (8 CPU, 32 MEM) to take care of the peak capacity of 100k users. In the traditional world, since there is no way to increase the servers size on the fly, the server capacities would have  built in headroom of around 30-40%. That means, you are paying for that extra headroom on top of paying for unused capacity during non-peak hours (~20k users).

To use the feature of auto-scaling, the application needs to be prepared for it.

Identify what is the non-peak traffic, and what capacity is needed to handle that. Then divide that capacity by 2 and split it into 2 to ensure you have availability.  One in one AZ / Region and the other in another AZ / region. So to manage the peak capacity, you might have 8 of L (2 CPU, 8 MEM) servers handling it, instead of only 2 2XL (8 CPU, 32 MEM).

Move Rocks into Cloud

In the extreme case that the application hard-coded nodes cannot be changed (lets say A,B,C,D), then you can still have only A, B running during non peak hours and setup the auto-scaling in the below way

  1. Launch all the nodes (A, B, C, D) in appropriate EC2 instances (E1, E2, E3, E4)
  2. Take an independent image of each of the nodes (Ai, Bi, Ci, Di)
  3. Store the images in S3
  4. Terminate E3, E4 instances that host C, D nodes
  5. Put the auto-scaling feature to bring up additional EC2 instances if needed.
  6. Put the configuration to launch Ci first, then Di

Of course, this is just taking care of the half of the picture (ramping down when not needed) and does not care of the unplanned peak (ramping up beyond the 4 nodes). Moving rocks into cloud does come with its own limitations, so it is always good to make the application cloud-ready from the ground up.

Readings on auto-scaling, in case you have not looked at it already

http://docs.aws.amazon.com/autoscaling/latest/userguide/auto-scaling-benefits.html

 

Leave a comment Posted on Outdoors

Camping Checklist

2015-08-23_225634000_17420_iOS

Sivananda Yoga Ranch, Woodbourne, NY, Aug 2015

Camp List

  1. Tent, Tarp
  2. Sleeping bags, pads and pillows – 2
  3. Camp chairs
  4. Fan, Lantern and torch light
  5. Firepit grill, tong, lighter
  6. Small speaker

Hygiene and Toiletries

  1. Sun screen
  2. Bug repellent
  3. Hand sanitizer
  4. Body Wipes, Shower gel, Deo, comb, gel
  5. Toothbrush / paste
  6. First aid: Tablets, etc

Clothes

  1. Hike pants, Ts, Cap
  2. Sleeping pants, Ts
  3. Hiking shoes, Socks and Sandals
  4. Small backpack
  5. Swim trunk
  6. Misc : Towels, Eye Cover

Kitchen

  1. Spoons, Forks, Knife, Bottle Opener
  2. Plates, Bowls, Glasses, Cutting Board
  3. Stove, Cylinder, Cooking vessels, spoons
  4. Ice Pack
  5. Vegetables:
  6. Fruits:
  7. Energy Bars
  8. Juices
  9. Water:
  10. Garbage bags

Misc

  1. Cash
Leave a comment Posted on Outdoors

Ski trip Checklist

Ski

Okemo Mountain Skiing, Vermont, Feb 2015

On the Slope

  1. Thermals pants
  2. Thermal long sleeves
  3. Snow pants
  4. Jacket
  5. Inner Gloves
  6. Outer Gloves
  7. Socks
  8. Face mask
  9. Goggles
  10. Helmet /  Ear muffs / Hat
  11. Energy bars
  12. Hand / Toe warmers
  13. Hydration packs / Water
  14. Advil / Ibuprofen

Off Slope

  1. Swim shorts / suit
  2. Regular wear
  3. Footwear
  4. Toiletries
  5. Chargers
  6. Food Items
  7. Water
  8. Sodas
  9. Beer
  10. Wine
Leave a comment Posted on Technology

/The flight plan

Rocket Garden, NASA, Cape Canaveral

Rocket Garden, Kennedy Space Center, Florida, Jul 2017

Migration of the applications can become very painful for the organizations. Any medium sized organization has anywhere between 500 – 1000 applications deployed, spanning over multiple departments. Assessing the applications as per our / Will it fly? guidelines is just one step of the process. Applications that were cutting edge at some point of time, might no longer be maintainable due to lack of the right resources. There might be very small applications that are used by a handful of people. And there might be applications like the company directory which have hooks from each and every application.

In fact, the bigger and widely used applications might have a cleaner migration path when compared to those pesky ones which are lying under the desk.  Creating a recommended application migration path becomes very important.

The standard application migration paths can be categorized as below. What we need to identify is the ‘best fit’, as inherently any migration path will have its own advantages, costs and pitfalls.

  1. Re-host: Is the application already in a container (e.g., Docker)? Or is it a standard Java application that is running on the standard Linux box? Applications like these can be migrated with minimal changes. The anticipated changes for such applications should be limited to simple configuration changes like interface changes, connector changes and URL changes in the configuration files. Applications like these might be hard to find in an organization that has not kept up with the changing technologies.
  2. Re-factor: This is the path that most of the applications might end up taking. This path is an effort only to make the application ‘cloud compatible’, by changing hard bindings to loosely coupled links. This would need code changes and rewriting of some of the interface components. There might be a possibility that the application is not yet raking in all the advantages of cloud.
  3. Re-architect: Cloud is different. It provides clear advantages to applications that get designed as cloud-native applications upfront. Components are loosely coupled, can scale up/down effortlessly, and are fault-tolerant. Two types of applications can take this path; an application that clearly needs the capabilities of cloud or the application needs significant changes to be migrated.
  4. Remove: Every organization will have gone through changes. Mergers, spin-offs, changes in direction in the company, a proposed consolidation of applications; all these lead to applications losing relevance or getting duplicated. The migration event should be used to retiring such applications.

The effort is to identify the best-fit. Review all the parameters before the application has been marked for any of the four paths, and be flexible in marking a different approach that is best-fit for your organization.

Drive to: /What goes well with your Cloud?