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?
Siesta Key Rum Distillery, Saratoga, Florida, Jun 2017
The advent of cloud brought a together tools, products and concepts that work very well with each other and enhance the overall experience. These tools and concepts might not be new, are not necessarily limited to Cloud and many companies might already be doing as part of their regular process
- Separate the compute layer and the storage layer. (Storage layer does not restrict to user data. We are also talking about run time files, shared network files in traditional models
- Micro-services: Split application requests into small chunks and then tie it up with an independent scale up/down. (e.g, If only name is needed, don’t request for a complete person profile)
- Containerize: Extract the application into a container by itself, so that it can run independently and can also be spun up along with the configurations, libraries and dependencies. (Docker, Mesos, Kubernates, etc)
- DevOps+CI/CD processes: DevOps is big. The merging of Development and Operations has brought together tools that help streamline activities in a better way. Continuous Integration / Continuous Deployment has redefined the entire release process
Tools like Maven, Jenkins, Chef, Ansible, Puppet help in automating the entire release cycle.
Next stop: /A new home
Saguaro National Park, New Mexico, May 2017
Well, it has wings, an engine and a set of wheels. But is it ready? How many different types of planes are there? Which engines do they use? Are the right pilots available for the plane? The question is – Will it fly?
To arrive at a conclusion, analysis has to be done on all the applications in the organization by collecting the relevant parameters. Start from the company CMDB (Configuration Management DataBase) to collect basic information
- Application Profile: It is important to understand the application profile holistically. What does the application do, what is the business value, is it Platinum, Gold or Silver application. What are the business dependencies of the application. Who are the users, owners and the relevant stakeholders. Are there multiple environments? All such parameters will help us in planning for the actual move.
- Technical Profile: Technologies used. Which technologies have been used in the development of the application? Which operating system? What products have been used, if any? Were there customization done? Is it already containerized? Are there dependencies on the other systems in the organization? What are the dependencies? What are the interfaces (data to / from). How does the licenses work for the products? What kind of support is already available? Do we have resources knowledgeable to provide all the details of the application.
- Infrastructure Profile: There are some fundamental differences in the way the traditional data centers are structured versus Cloud. For example, SAN and NAS form the core in the traditional data center, but in the cloud storage is accomplished by Block and File Storage. Are the applications hosted on physical machines or are they in VMs. Are the VM images available. What are the network interfaces. It is important to gather information regarding the servers that are used, and the networks, storage and the ‘hooks’ into various systems.
- Data Profile: How are the licenses structured for the application? What about data storage? Does the data need to be encoded in transit and and at rest? Does the application store PII (Personally Identifiable Information). Are there any specifications needed for that?
Based on the information, derive a ‘cloudability’ factor. This should give us on scale of 1-10, the ease with which an application can be moved to cloud – 10 being the easiest to move. This will also help in case a phased approach is being planned.
Merge into: /The flight plan