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
- Launch all the nodes (A, B, C, D) in appropriate EC2 instances (E1, E2, E3, E4)
- Take an independent image of each of the nodes (Ai, Bi, Ci, Di)
- Store the images in S3
- Terminate E3, E4 instances that host C, D nodes
- Put the auto-scaling feature to bring up additional EC2 instances if needed.
- 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
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.
- 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.
- 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.
- 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.
- 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?